When you think of being agile, what comes to mind? I doubt Flow Efficiency is the first thing you think of. My guess is it might have something to do with value delivery, methodologies, frameworks, events, or roles. These are all things that we sometimes hear people say when we ask them what “good” looks like for them.
After that, the conversation usually turns to how they want their teams to improve: to be more efficient. So how do we measure this efficiency? Story Points delivered? No. Throughput? No. In this case, we need to look at Flow Efficiency.
What is Flow Efficiency?
Flow Efficiency is a measure of how much time we spend working on something as it passes through our system. We calculate it by measuring the total elapsed time it takes to complete a work item from our system's perspective (sometimes known as “Lead Time” or “Cycle Time”). Then we calculate the amount of time that work was in an active state (“Active Time”) – that is, not waiting around, sitting in a queue.
We then calculate the system's Flow Efficiency like this:
Flow Efficiency = (Active Time / Total Elapsed Time) * 100
Low Flow Efficiency in Organisations
Often when you measure the Flow Efficiency of a team which uses Scrum or Kanban, you will find that the Flow Efficiency can be high double digits. However, when we look at the organisation level, the end-to-end Flow Efficiency is often low double digits or even single digits. The temptation is to throw a lot of time and effort at the teams to improve an organisation's Flow Efficiency. When we have seen companies do this, they shift the dial up even higher on the team level which is great. However, how does it impact time to market, value delivery or responsiveness to market conditions?
The sad fact is that in many situations, it doesn't improve the end-to-end Flow Efficiency so it has no impact on business performance. This shift gives us a false sense of achievement and is a terrible waste of effort.
So what's going on? Let's try a little thought experiment involving a Milk Float and a Sports Car.
The Sports Car and The Milk Float
In the UK, Milk Floats were a common sight up until the early 1980s. These battery-powered workhorses of their day used to trundle around our streets and towns at the princely top speed of 16 miles per hour as they transported fresh milk to homes and businesses.
Contrast that with a Sports Car. Let's take something of a similar time period. In 1982, the world's fastest production car was the Lamborghini Countach LP 500S. Its 4.8L V12 engine could reach speeds of up to 182 mph.
What's this got to do with Flow Efficiency? Well, put a Milk Float next to a 500S in a drag race and I think we can all agree that the Lamborghini is going to win hands down.
How about in a traffic jam? If a Milk Float and a 500S are side-by-side in gridlocked traffic, who is going to get where they need to be the quickest? Which driver is going to be sitting in their vehicle most frustrated? Which vehicle has the largest overheads (insurance, fuel, etc.)? Who spent the most money to get stuck in a queue?
What is our first thought when we think about improving our time to market? A common answer we hear is “I want my teams go quicker.” In other words, how can I upgrade my Milk Floats to supercars?
What Does This Have to Do with High Performing Teams and Flow Efficiency?
Imagine that you have taken your team which has low Flow Efficiency and turned them from a Milk Float and in to a 500S… and then you put them in a traffic jam. What do you imagine will be the result? Teams believing that they are knocking it out the park? Of course. Time to market improvements? Unlikely. Business Agility? Sadly not.
What most agile transformations do is upgrade teams in isolation of their wider context – this is the local optimisation trap. I believe that this is a reason that many transformations fail. Everyone tries to upgrade teams to a 500S at great expense, but the traffic jam remains. We improve the top speed but we don't improve the traffic conditions.
This is the hidden truth of Agile Teams. In most organisations, it simply doesn't matter if the teams are high performing, because most of the time the work sits in a queue. Work waits for space to clear so it can move. Then it moves very quickly and noisily to the end of the space, only to queue again.
We suffer a crisis of agility because we don't apply the same thinking to organisation that we do to the team level. It's like we check the box of “having agile teams” and then wonder why we see no improvement.
How do we fix our Business Agility?
A good start is to model our end-to-end flow. At the very least this will provoke improvements to our organisational Flow Efficiency and therefore our time to market. We need to watch the ball, not the player if we want our business to become agile. At an organisational level, reports of <5% Flow Efficiency are depressingly common.
Another useful thing to consider is the question of “are we sending the right things to market?” In truth, we can only know this once they have gone to market, however assuming we have a strategy, then we can align our execution to our strategy. A fantastic way to improve the agility of your business is Flight Levels. Visualise your strategy, your end-to-end flows, your dependencies and your delivery. Model the flow of information through your organisation and agree on how best to manage it. And above all, improve.
To learn more about Business Agility, take a look at our Flight Levels Systems Architecture (FLSA) course.