Flow metrics are not manufacturing metrics
Why you should measure flow metrics in software development
There is a common misconception even among very knowledgeable people in the software industry, especially software engineers: the idea that metrics like cycle time and throughput are only relevant to (supposedly simple) repetitive processes that “produce the same thing over and over again.”
Software is different, so the thinking goes.
We do “knowledge work” in software.
If you use “manufacturing metrics,” you are trying to turn software development into an assembly line operation, constantly churning out useless features without considering whether or not they are delivering value.
If we want to understand anything about a software process, we should use qualitative methods more suitable for human activity.
We should do the work, ask the teams what they need, discuss among ourselves, and learn how to improve through empirical observation.
We should not graft “Tayloristic” approaches more suitable for mindless grunt work than intellectual work.
It will all work out when we deliver “value.”
—-
Like with most simplistic analyses, these observations have a very strong kernel of truth.
The nature of software development is indeed quite a bit different on the surface than manufacturing.
But the key point is that the human systems that produce software are not all that different from human systems that create complex products in any industry.
The core activity in software development, a team of people collaborating to define, make, and ship changes to a shared codebase, is a complex human activity, no question.
But most of the real complexity lies in the communication, collaboration, and coordination needed to make that happen, not in changing code.
Developers, in particular, attach much more mystical significance to this latter aspect of software development than is warranted.
If changing your codebase is such a mystical, unpredictable activity all of the time, it is a symptom that you are probably not doing good engineering work in the first place and your development processes are poorly designed.
And if you think “manufacturing” is simpler, talk to an operations manager at a modern manufacturing plant dealing on a daily basis with just-in-time inventory management, with parts sourced from a global supply chain.
I have.
The planning, coordination, communication discipline, and agility needed to keep your “simple repetitive manufacturing process” from falling apart on a daily basis are often mind-bogglingly complex.
Much more so than the stuff that software teams ever have to deal with.
We have it easy compared to them.
—-
So, why measure flow metrics in software development?
It is to analyze the flow of work through your system from end to end and understand whether or not your development process is stable.
And if it is not stable, understand what you need to do to bring it closer to a stable state.
Most of the dysfunctions in modern software development can be flushed out and solved systematically by first driving the end-to-end product development process, from ideation to adoption, from unstable states to stable ones.
It will surface problems with planning, coordination, and communications at a system level and in each part of your process.
It will give you concrete data to figure out how you should restructure the way your teams are organized to maximize flow.
It will surface opportunities to improve the flow of work through the system much more clearly, and more effectively than any amount of empirical observations or asking teams on the ground for their opinions ever will.
And why does stability matter?
You can plan and deliver work in a much more sane and humane manner when your system is stable.
There are proven theorems and math that underpin these techniques, and these apply equally well to software development.
So it’s not a matter of anyone’s opinion whether it will work.
It will work once you learn how to apply the rules of flow properly.
What it primarily needs is discipline.
From all the humans involved at every step of the process. Engineers, managers, leaders, everyone.
And this is hard.
This is where the uniquely human aspects of software delivery manifest themselves.
But that’s the main reason to measure flow metrics in software development.
So we can have objective data to see where problems with product development flow are both systemically and on a day-to-day basis and how to fix them.
Once you reach a stable state, we can start talking about your “performance” and “productivity” and how you can improve them, but that’s not what flow metrics are meant for.
So, what is stability?
How do we use flow metrics to make a system stable?
This is the next post in our series.