In football, the team that wins is the one that gets the ball in the other team’s goal most times. Not the one that runs the most. What matters most is what is happening to the ball. So, we need to watch the ball, not the player.
Business is no different. In Knowledge Work what matters most is what is happening to the work, not what the workers are doing. Our focus needs to be on improving the flow of work and one excellent business metric is the Flow Efficiency of your process.
Flow Efficiency is the amount of time a piece of work has been worked on compared to the total elapsed time it took to deliver the completed work. We also call this the Business Process Efficiency.
Flow Efficiency is one of the most powerful business metrics we can measure and use in Business Agility. Unfortunately, it is also a complete blind spot for most businesses. It is a metric many fear and resist to engage with.
Why? Often, because the initial measure tells us that we run our businesses in atrocious ways. In fact, we do it so badly that we often can’t accept the figure we see. So, time and time again, companies get so discouraged by the number that they reject it or try to change the data to make the number more tolerable.
How bad is it? Bad. Very bad. Håkan Forss and Zsolt Fabok have reported figures that are as low as between 1% and 5% efficiency. A Flow Efficiency of around 40% will put your company right at the top of the class. If you are not shocked by these numbers, perhaps it is (a) because you have measured this before and you already know it or, more commonly, (b) because you are failing to really grasp how bad this is!
What is Flow Efficiency?
To understand what Flow Efficiency is, I would suggest watching this excellent TEDx talk by Niklas Modig titled “The Efficiency Paradox” (18:48)
Flow Efficiency = (time spent working on the work / total time to deliver the work) * 100
So, if your Flow Efficiency is, say 5%, that means that, of the total elapsed time it takes to deliver a project, product or initiative, 95% of that time will be spent waiting in some queue for someone to do some work on it. This is so bad that we should stop pretending that our organisations are “value generation engines” and reframe them as “queue management entities”. Like it or not, if we analyse what the organisation really does, most of the middle management activity will be dedicated to managing these queues and reporting on them. We want to believe that we generate value. Sadly, we don’t.
Just think about the enormous financial waste we incur while work is queuing 95% of its lifetime. Not only the value and relevance of the work we have done so far degrades quickly, but the financial expenditure in managing, communicating and coordinating the queues grows exponentially.
A common mistake: Confusing Flow Efficiency and Resource Efficiency
Part of the problem is the mindset that has been taught to most business leaders — primarily, the unnecessary, and often damaging focus on Resource Efficiency. You probably know this as “Utilisation” and it is how most companies are managed. We meet managers that believe and say things such as “the key to running a business is to have every worker as busy as possible. The busier they are the more they’ll produce. Just give me 120%, damn it!”
Resource Management may have worked really well in a manufacturing context. However, in Knowledge Work it is a ticket to business oblivion. To succeed in modern complex business environments requires us to adopt an alternative way of thinking, which is where Flow Management comes into play.
However, making the transition to Flow Management takes time and presents its own challenges. Even after over a decade working with flow-based approaches, I still find myself gravitating towards traditional resource-based thinking. It is fundamentally important that we are aware of this and catch ourselves when we do it.
Here is a simple example of a question I received some time ago that shows how we struggle to differentiate Flow Management from Resource Management:
I have an 8 hour task to do in one day, but I spend 2 hours on it, and 6 hours on stuff that isn’t on the board. That’s an easy calculation. However, what if I spend 2 hours on that task, but then 6 hours on another task, for another epic? Does my flow efficiency not change? Or does it become worse, because I switched epics, and flow efficiency is focused per epic? Does that make sense?
As you can see by now, there are two efficiencies in play: Resource Efficiency (utilisation) and Flow Efficiency.
- In both these examples, the person is fully utilised (actually, this is often a bad thing in complex work).
- However, Flow Efficiency focuses on what is happening to the work. Of the total elapsed time it takes to complete a piece of work, how much of that time has the work spent in a queue? How much time has been spent actually working on it? That is what gives you the Flow Efficiency measure.
This is the kind of confusion I see all the time. We are so focused on resource utilisation, that it is hard to realise that even if people can be 100% utilised (efficient resource), the work can spend most of the time idle (being unutilised) in a queue (inefficient flow).
In Lean and Agile we’ve known for a very long time that our measure of progress is completed work that meets the needs of a user. Assuming this is true, then, what we should aim for is 100% utilised work (efficient flow) done by people with spare time (Slack) that can absorb the inherent uncertainty of our work environments (inefficient resource).
Helping Flow Efficiency Emerge
A few years ago, Pawel Brodzinski wrote two highly influential blog posts on the “myth of 100% utilisation” (2012) and the “Economic Value of Slack Time” (2015).
In his articles, Pawel illustrates the negative impact that high utilisation has to knowledge work. He also provides a very persuasive case for the importance of creating spare capacity (also known as Slack) in the work environment.
When we focus on maximising utilisation, the time it takes to complete the job grows exponentially. If we want to reduce the time to complete the job, then we have a business trade-off as the cost of spare capacity increases. Considering the three parameters (utilisation, time and cost), there is a level of utilisation that generates an optimal trade-off between the cost of spare capacity and the time to complete the job.
Many people really struggle answering the question “how do we create the Slack, then?” When we talk about utilisation in this way, we are referring to how busy people are. Our mind locks on Resource Management solutions (eg. give people less work). That’s not it — this will not work if your organisation (un)consciously values “being busy”. What we need to do is to refocus on what is happening to the work and, specifically, in identifying Flow Management solutions. In Kanban we have a wonderfully powerful tool to help us refocus: Little’s Law.
Little’s Law establishes that there is a relation between how much work is in process (WIP), the time it takes to complete the work (Lead Time) and the amount of work you can deliver (Throughput).
Average Throughput = (Average WIP / Average Lead Time)
If we want to create Slack and improve efficiency in our system, the first thing we can do is to Balance the WIP — usually by reducing the amount of Work-in-Process. This makes sense, because if you remember, we want to focus on solutions that target the work, and changing the WIP is, at its core, an intervention focused on the work. When you achieve a more balanced system, the result is that work will flow more smoothly and faster. The impact on the people is that they will not be running around like headless chickens with too much work. This leads to the appearance of Slack. Having Slack soon becomes a business asset as people:
- Have time to absorb the variability of work
- Start truly collaborating
- Improve their work and their processes, and
- Remove the sources of delay & waste.
Completing work starts becoming more predictable, trust in the process increases, people have more opportunities to self-organise and so on.
Balancing WIP generates the conditions to improve Flow Efficiency. It also enables virtuous feedback loops that lead to successful, healthier businesses.
Flow Efficiency is a Business Metric
In my article “How well does your system flow?” I argued that “Your biggest improvement opportunities are not at the team level”. This is also true for Flow Efficiency calculations. The true dimension of this metric is not at the team level, but at business level.
In fact, Flow Efficiency at team level is often misleading and risky. The greatest causes of delay, waste and poor flow are simply not present in sufficient strength at the team level. Not only that, many improvement interventions are often done at team level only. This can increase the local efficiency of a team, but reduce the efficiency of the overall organisation. In Systems Thinking terms, calculating Flow Efficiency at the team level can lead to local optima instead of creating systemic improvements. Unfortunately, a lot of what we see in the Agile space is full of localised team level improvements.
Flow Efficiency really shows its impact at a higher organisational level (strategy, product, projects, initiatives, etc) where things like delays, uncertainty, coordination and interdependence really show up (often with a vengeance).
of interdependent business cells
If we learn to see and understand our organisations as complex systems of interdependent business cells (teams, services and/or functions), then we soon realise that what really impacts our companies’ ability to deliver work is not what happens inside the cells, but what happens in the space between the cells.
I’ve worked with organisations that only measure Flow Efficiency at team level. They can get localised results above 50% efficiency (not surprising in many agile environments) and then claim that “Flow Efficiency is not a problem for us”. What they may not even be capable of doing is measuring the end-to-end Flow Efficiency of the business. When they do, then they get results as low as 1%…and that is a scary prospect to have to face up to and deal with. One of the most open-minded clients that my company, Actineo, worked with faced this situation and, at least initially, completely refused to measure end-to-end Flow Efficiency. It was just too painful for them to even consider it.
Conclusions
Flow Efficiency is one of the most powerful business metrics we can use. Introducing it can cause significant levels of business anxiety, and will most likely require a careful approach. There is a time and place to start introducing it, but once you find the right time, then it is a great enabler for organisational improvement.
Improving Flow Efficiency in an effective manner requires us to be able to look at our organisation from the perspective of what is happening to the work. It requires improvements that are based on Flow Management principles. This transition to thinking about managing the work and not about the “resources” is core to becoming a successful Knowledge Work organisation.
Being able to do Flow Management is hard, but it is well worth it. People and business alike are much better and healthier with it. The scrum.org Professional Scrum with Kanban (PSK) training course is a first step for Scrum Teams to add powerful Flow Management concepts to Scrum.
Reference Materials
- [Blog] The Busy Bee Paradox by Håkan Forss
- [Blog] Flow Efficiency by Zsolt Fabok
- [Blog] Flow Efficiency: A great metric you probably aren’t using by Julia Wester
- [Book] This is Lean by Niklas Modig
- [Book] Actionable Agile Metrics for Predictability by Daniel Vacanti
- [Book] Rethinking Agile by Klaus Leopold
Credits
- Photo by Jannes Glas on Unsplash
- Special thanks to my fellow PSTs for the contributions and feedback: Jean-Paul Bayley, Steve Porter, Massimo Sarti, Glaudia Califano and David Spinks
- Also thanks to the following colleagues for their contributions and feedback: Vic Page, Paul Brown, Vlad Mihailescu, Markus Hippeli, Olga Heismann and Martin Jewiss