Not like this …
Squiggly lines over neat boxes in corporate, agile development
Inspired by Henrik Kniberg’s classic illustration on agile, iterative development …
… I have been thinking recently on what agile looks like in a large, corporate environment. I have used Henrik’s analogy of how to build a product (a car in his illustration) in an agile way many times in coaching squads. Its a powerful teaching tool.
However the reality, especially in corporate environments, is as always more nuanced. Rather than one squad building one product we have multiple squads building multiple products, many of which are supplying internal products and services to other squads, and so on.
Not like this
I have seen many “roadmaps” that lay out the work for the tribes and squads (or departments and teams depending on your language of choice). They look good; they are visually neat and they fit well with the quarterly OKR cycle many corporates employ. In addition these top level boxes can become “epics” in Jira or ADO, then broken down into “stories”, packaged into a sprint and hey presto!… instant agile!!
However this approach simply can’t cope with the change and complexity of what technology teams do today. When combined with heavy-weight quarterly planning processes it is simply too cumbersome and brittle. Which is not to say that this approach does not yield any results at all — it can be reasonably effective. However as companies seek that all important competitive edge they find themselves not keeping pace with those organizations who can, as the agile manifesto has it:
“harness change for the customer’s competitive advantage.”
Like this
The alternative is to let go of our desire to have everything fit into neat boxes and embrace an approach that lets individual teams work their way towards a business outcome. This can be a messy process — as the team navigates the complex landscape of a corporate environment and makes discoveries, today’s sprint goal can become tomorrow’s wrong approach. This can be a scary place to be for leadership to be in. It feels like losing control. In fact, it is relinquishing the illusion of control, which is the first and necessary step towards true change.
Furthermore, this approach is not simply to “let the squads get on with it”. Each squad should have a clear purpose and define clearly how they interact with other teams. Team topologies calls this a team API
The role of leadership
The role of leadership in this model does not diminish. It is not simply to encourage the squads, or model vulnerability (although these are good things of course). The role of leadership in this model is
- To architect the team purposes, and to continue to keep purpose architecture relevant through organizational change.
- to continually communicate and refine these goals and outcomes. In the best of all worlds this is done collaboratively with the teams. However leadership must drive this.
Where are roadmaps in all of this?
This approach also doesn’t preclude a roadmap, which can exist at a squad level, or project or programme level. We can peer into the mist of the future and make out the major shapes.
Roadmaps are a balancing act. Teams and especially management need a degree of certainty. It is just as true to say that teams and especially management need the flexibility to be able to respond to change and to pivot if that becomes required.
A good roadmap will strike that healthy balance
So next time you are in Big Room Planning,
take a look “under the hood” at what is happening. Is the objective to get the big boxes to line up like good soldiers so they can be entered into Jira, or do the conversations center around the team purposes, team APIs and how they align to leadership’s current perspective on the goals and outcomes.
Remember….
