Stable does not always mean steady
Unwinding a common myth about stable flow
The idea of stable flow often conjures up a picture of an assembly line churning out identical widgets of the same size and shape at a steady rate.
In fact, a system can be stable even if its outputs are not steady, and a steady output does necessarily mean the system is stable.
A stable Scrum?
Consider a team that delivers a single feature towards a sprint goal in a 2-week sprint, followed by a 2-week sprint where they work with users to fine-tune the UX based on feedback and repeat this over and over again consistently.
This process will have very different outputs (cycle time and throughput) if you measure them sprint by sprint.
The size and shape of work between sprints will probably look quite different. Their outputs measured over two-week windows may not look very steady.
But this can still be a stable system, provided all work that starts in a sprint is finished within a sprint or two.
In fact, setting a single sprint goal and pulling work into sprints based only on this goal can be a very effective mechanism to achieve stable flow.
Stability is a business goal.
When talking about stability, the observation window you are measuring over and the frequency with which you take measurements (to compute averages) are very important.
For example, in our example above, if you take repeated weekly measurements over 30-day windows, you may find your output metrics are steady, and the system meets the conditions for stability, even if they are neither when measured across a narrower observation window of two weeks.
The trick, of course, is to make your system stable over an observation window and measurement frequency that meets the needs of your business.
This is determined by how quickly your customers need you to ship changes to them and how quickly you need to respond to their needs to compete effectively in the market.
In general, the steadiness of output is not easy to achieve because of the nature of software development, but it is not particularly important anyway.
What matters is the stability of the whole process.
A stable system only starts as much work as it can deliver within an observation (execution) window, which then makes it easier to coordinate the flow of work between product development and the rest of the business.
A stable flow is the first step in being able to synchronize your product development process with the pace at which your customers need you to deliver for them, and the conditions of stability provide a wide range of options to design a process that lets you do this.
What makes a process stable?
In general, you can’t say anything about stability simply by looking at the steadiness of its outputs.
You have to look at the outputs relative to the work in progress over an observation window that the business gets to choose.
What matters for stability is that the WIP and the average age of WIP stay bounded over a suitably chosen observation window, that work starts and finishes at roughly the same rate, and that you finish all the work that you start.
We discussed this in more detail in our earlier post, Stability, First.
These are fairly weak requirements, and there are quite a few different ways to meet them.
You can lean directly into the manufacturing analogy as Kanban does, hold your WIP constant, and use a disciplined policy of only pulling in a new item when some item finishes.
This will give you steady throughput but not necessarily a steady cycle time or a stable process unless you also place a limit on the age of WIP.
For stability in a software process, you need explicit policies in your process to manage both the WIP amount and the aging of WIP.
Further, no matter what methodology you adopt, you need to have some way of ensuring that work keeps moving.
Otherwise your process will never be stable.
Which quadrant is the right one?
In the figure, we give some examples of choices that can meet the requirements of stability, steadiness, or both.
Note that we are not suggesting that these are directly tied to which methodology you choose, just that well-functioning implementations of these choices will tend to fall into these quadrants.
Of the four quadrants in the figure above, the only one that is always undesirable is the top right one, where the process is neither stable nor steady.
You get this when you have unmanaged WIP and unmanaged scope/aging of work.
Depending upon the economic model of your business, any one of the other options might be a workable solution for your context.
Stability is a goal you aim for no matter what methodology you adopt.
Even an ad hoc one.
And the great thing is that stability represents a process-agnostic process outcome that you can measure without knowing anything about the specific process you are using.
Most of the current methodologies we have today get us a good part of the way towards achieving this, provided you factor in the need for stability by focusing on how you scope work, manage WIP and start what you finish.
This is what makes the concept of stability so powerful to cut through the noise of the methodology wars.
Unfortunately, the parts you need for stability are often left out of the standard playbooks people get when they adopt one of these methodologies.
So in practice, you can implement a process that falls into any of these quadrants, no matter which methodology you choose.
Most real-world implementations of any of these methodologies are neither steady nor stable.
Still, stability is the problem we need to solve to make the process work for the business.
In the end, stability and steadiness are not something you get from the choice of your methodology but from how well you implement them with a clear focus on stability.
It does not come for free simply by the choice of your methodology.
In any case, don’t fall into the trap of thinking that trying to make software development stable means forcing the work to look like assembly line manufacturing.
That’s just a myth.