Scaling Agile Capabilities

It is my experience that people who think about how to achieve more organizational agility benefits from looking at things from a business capability viewpoint before thinking about organization, tools, and what agile frameworks to experiment with.

A business capability is the ability for a part of the organization to meet a need, internally or externally. The capability could be translated into an expectation of what a part of the organization can provide rather than how it is achieved. For instance the capability to create an increment of valuable deliverables at regular intervals, or the capability to provide a clear answer on what the most important thing is right now.

Methods, frameworks, collaboration techniques, particular roles et cetera is on the other hand totally focused on the how. The capability to create a valuable increment at regular intervals has to be performed by a single cross functional team according to some, the capability to answer on the organizational priorities has to be performed by a single person whose name will be "Product Owner", and so on.

The methods holds a promise: follow me and the capability will emerge! And it is true that these tested techniques often delivers. During my last ten years of experimenting with agility I have tried many of the techniques others have used and written about, and we have achieved pretty good results with them.

But it is also true that we have applied the same techniques in other places and seen things become worse. So it is clearly not the techniques themselves that generates the outcome, but the application of them in environments where also other factors contribute to the result. Of course. Collaborations are complex systems. You can never attribute success to only one thing. Every situation is different and small changes in the circumstances have a huge impact on the result.

Controlling the outcome in a complex environment requires tweaking. We need to steer the system empirically: inspecting the situation and the desired outcome, adapt the action, inspect the result of the adaption, and so on. This is the very heartbeat of anything lean and agile.

Focusing on the desired business capabilities gives you a view on the outcome. What is it that you want to achieve? What is the need?

In some environments it takes a couple of specialized teams to create value. It is as of now impossible for a single team to do this in isolation. So you need the capability for teams to plan, execute, and follow up together, just as they do as individual teams. You could use the Nexus collaboration patterns for this, or organize into a release train as SAFe describes, or trying something else, but it is the capability of many teams acting as one that we need.

In some environments it is hard to create value in chunks that are independent, valuable, and small at the same time. In those environments it can be helpful to think about independent business epics, valuable features, and small slices, as three separate things to manage in different levels of the backlog. Because we may need the capability to divide, explore, and prioritize epics, features, and slices in different ways using different cycles (not all information flows at the same rate).

This is a way of thinking and discussing needs and how to meet them. It lifts us above meaningless quarrels on what processes and tools we should use and instead helps us focus on the good interactions between people. Talking about business capabilities, thinking like agile business architects, is a way of dealing with systemic needs and the different ways of meeting them.

I have found the perspective quite helpful.