The metrics covered in our Flow Metrics Basics class show how to measure different aspects of flow, but those metrics don’t in themselves, show how to improve the flow. We’ll look at one way to improve now.
Let’s consider a possible workflow for a story that comes to a development team.
- Idea forms
- ⮕ Story is created and placed in backlog.
- ⮕ Team refines the work and gets it to ready
- ⮕ Team does planning and pulls it into a sprint
- ⮕ Developer writes code and opens PR
- ⮕ Other developer reviews PR and provides feedback.
- ⮕ Developer reviews feedback. If changes needed then back to 5
- ⮕ Developer merges code
- ⮕ Someone deploys to test environment
- ⮕ Tester tests code and if bugs found then back to 5
- ⮕ Code is deployed to prod environment
- ⮕ Code is released (turned on)
- ⮕ Users begin to use code
When we’re asked to look for improvements in this system, we might look at how fast we’re coding and introduce some new tooling. We might look at how long the test cycle takes and add more people or start to automate some tests.
Where we don’t typically look for improvement is in the wait states, and yet that’s where we could get the biggest impact.
“In product development, our greatest waste is not unproductive engineers, but work products sitting idle in process queues.”
— Donald G. Reinertsen,
“The Principles of Product Development Flow: Second Generation Lean Product Development”
Every “⮕” in the list above is a wait state. It’s a point where the work was just sitting, waiting for us to have the time or capacity to pick it up. In most cases, the time in those wait states is significantly longer than the time that we’re actually adding value to the work. Ten times longer, is not uncommon.
This ratio of time adding value against the total time is called Flow Efficiency and is a metric that is extremely useful, and yet also extremely difficult to effectively measure.
Let’s look at a couple of these wait states:
Example 1: Idea forms ⮕ Story is put on backlog
We have a thought, and talk about it. Maybe we write it down, maybe we table it for a different discussion. Eventually we understand it well enough to start writing it down so we open a ticket and put some words around it. Over days or weeks, we periodically learn more and update the ticket with those details. This stage can take anywhere from days to months before we have enough in the ticket to move on.
Example 2: Developer opens PR ⮕ PR Review ⮕ PR merge
It’s quite common that as soon as the developer opens the PR and sends it off for review, they switch to some other piece of work. At some point later, often days later, another developer reviews that PR and either approves it or requests changes. By the time it comes back to the first developer, they’re usually deep in the next piece of work so it takes time to get their head back in the original code. Perhaps they agree with the feedback or perhaps they don’t. Maybe they add comments and send it back to the reviewer. I’ve seen this go on for weeks.
It’s possible to get PR’s done quickly - I’ve heard stories of teams that can get PR’s done from creation to merge in ten minutes, although those are very rare. I find that PR’s typically take days to weeks to complete, and almost all of that time is waiting.
The workflow above is a fairly simple one where a single team can do all the work themselves. In most companies, it’s more typical that work has to pass through multiple teams before it’s in the hands of users.
One client of mine had seven teams in between idea and use. For a new feature to be implemented, it had to pass through seven different teams, every one with their own product management and development and test. It took months to get anything done.
When looking at how to speed up the system, we usually focus on those places where we’re adding value. Let’s improve the coding or the testing or the brainstorming. Yet, those places are often less than 10% of the total time it takes to get things done.
A while back, when we were both working with the same client, Dave Nicolette ran a fascinating experiment with a team in visualizing these wait states. I won’t recap the experiment itself as he’s done an excellent write-up of it here. I do want to talk about the behavioural changes that we saw, just from visualizing wait states.
Within days of starting to visualize active and wait states, we saw that teams started declining meetings that they’d insisted they could not decline previously. They’d been adamant that they had to go to every one and yet, once they started to see how long the work was sitting idle due to those meetings, they decided that perhaps they didn’t need to go to all of them. Or perhaps not as many people needed to go to those.
We saw people starting to collaborate on work in ways that they’d previously insisted were impossible. They’d originally said that the nature of the work made it impossible to do any real collaboration so everyone worked in a silo. Yet, when the wait states became visible, they immediately found ways to collaborate on that work more effectively. Ways to have fewer things in progress at once and to get work items completed faster.
Just visualizing the idle time, led to immediate behaviour changes.
If we want a real speed improvement, we should start with eliminating wait states.