11 tips for utilizing flow efficiency to boost performance!

Flow efficiency - the art of achieving (sometimes significantly) more without working more. It's the Holy Grail both of Lean and Kanban. How do you achieve it?

Here are 11 actionable suggestions to get started on your journey to maximum flow efficiency.

1 - Map your process 

Do you know what happens between the time when a work item begins, and when it ends? By definition, a "process" is "a series of actions or steps taken to achieve a particular end."
In Kanban, the idea of process mapping should lead to a Kanban board - where each action becomes its own column on the board.

During this exercise, it's specifically important that you "focus on the baton, not the runner".

Your process is not defined by how your teams are organized or who has which skillset - it is defined by the works items being processed. Hence, your process mapping exercise should not focus on having people describe their work, it should be described by looking at the flow of work.

An example process map for development work

2 - Make wait time explicit

At every handover in the process, the work item will most likely spend some time waiting before being processed. There are two types of wait time in the process: inherent to the activity (for example, an analyst waiting for an appointment with a user), and inherent to the process (for example, a refined backlog item waiting to be picked up by a developer). Initially, we are only interested in the wait time inherent to the process. 

Visualize them on your process map:

A process map with "WAIT" markers

3 - Visualize processing time

The next step is to use whatever data (or experience values) you have in order to label the process with corresponding times for each step - weighted averages are perfect, averages are good - even guesstimates are enough.

A process map with processing time annotations

4 - Act on Wait Time

The definition of flow efficiency is the ratio of wait time vs. touch time, so in order to improve our flow efficiency, we want to see what we can do about wait time.
The elimination of wait time will improve both our flow efficiency - and our throughput time, without changing anything in "how" anyone works on any item.

There will usually be one step in our process sticking out, where wait time is higher than with all other steps. This is where we can have the biggest impact with the least amount of change:

Our example process has a throughput time of 40 days - a single change could speed it up by 20%!

5 - Focus on Throughput

The troughput rate is the ratio of inventory (i.e. WIP) getting processed per time. Based on Little's Law, you have two big levers to improve your throughput rate: Reducing inventory - and reducing processing time!

What many organizations forget, though: you have another lever on throughput: increasing the amount of WIP passing through your system!
The easiest way to do this is to examine the process for blockages: anything that leads to started work items to not move smoothly and uninterrupted through the process.

It's very common for organizations to suffer from various other causes of bloackages - including, without limitation: waiting for people or events, lack of materials (e.g. environments), higher priority work passing by, interference of other processes etc.

Identifying the common places where work in our process gets blocked.

6 - Understand constraints

 A common theme in every organization is that overburdening the process constraint causes blockage. When we push more work into a step than can be completed, some of that work will natually be blocked due to lack of capacity.
Unfortunately, in complex knowledge work, it's often really difficult to know why the constraint is constrained. And even if we have that knowledge, it may not even help us - because that's an action upon touch, i.e. trying to change how people work in the hopes that more work flows through the system.

It's also extremely important to remember that "constraint" and "bottleneck" are not necessarily the same thing:

Our process has two "bottlenecks" - yet only one "constraint" that defines overall performance!

Looking at the Step throughput rates data will reveal which step is the real constraint, and which is an irrelevant bottleneck.

Our example process is constrained by deployment: if we improve development, nothing will get better!

It's extremely important to understand this difference, because if we improve upon a bottleneck that is not the constraint, we will just shift the wait time downstream!

7 - Reduce workload

Organizations that specialize in departments tend to focus exclusively on department performance, and even teams with specialists tend to focus on role performance. Both of these are entirely irrelevant, as the only important performance metric is the overall system's performance: process throughput!

Reducing the workload sounds absolutely counter-intuitive to specialists, yet it's the most important in improving flow efficiency: it reduces in-process inventory, simply by starting less work.
Stopping excess work leads to "the baton, not the runner" moving significantly faster - no magic involved!

All the local optimization performance can be eliminated without affecting process performance!

While this makes every person with cost center responsibility cringe, we have achieved a seemingly miraculous change: we are working less and still get significantly better throughput rates - for free!

Let's do some number crunching to make the case with an example:
Previously, we had an average processing time of 40 days - and an average of 40 items in progess.
That means our throughput rate was 1. While we are still producing 1 item per day, this little tweak reduces the in-process nventory, which means the average age of items stuck in process goes down. By eliminating 20 items stuck in process, we double the throughput rate - to 2, which means work now flows through our process twice as fast!
And this is where things get magical: We have moved from acting upon processing time to acting upon excess inventory: Throughput optimization has become our lever for performance.


Nobody works harder, many people have less stress - results stay the same, yet process performance has doubled!

8 - Redirect excess capacity

The reduction of "blind effort" leads to a lot of excess capacity in the organization - capacity that is now free for anything except starting new work!

A question I like to ask in coaching, "What overburdens the Constraint?" - let's trust for the minute that work at the Constraint is already done as well as humanly possible, i.e. "everyone does the best they can".

In many organizations, specialization and a "my job is done" attitude has led to people involuntarily (or unwittingly) pushing work elsewhere, until it eventually becomes a burden on the Constraint, where then blame is placed for poor performance.
We need to reverse this mechanic and instead ask, "What work is being done at the Constraint that can be done by someone else - even if it's significantly less efficient if done by others?"

This does not mean that, for example, we will tell analysts or developers to perform Exploratory Tests. Instead, analysts could prepare test scenarios and developers could create small semiautomation tools that allow testing experts to proceed faster, which means the Constraint has less work in order to achieve the same outcome.

Relieving the Constraint of work increases throughput while (almost) everyone is working less and nobody is working more.

9 - Set the right Constraint

In most organizations, constraints exist simply because they happened to be where they are. A common "solution" is to hire more people to work on the Constraint, until the organization grows to a point where coordination of all the work in progress becomes the constraint - oftentimes leading to shadow inventory that exists beyond the coodinators' horizon.

A much smarter tactic is to deliberately place the constraint where it makes sense:

The best way to place the Constraint is to ensure that the most precious asset of the organization (i.e. the rarest skill, the most talented people, the most expensive equipment) defines the capacity limits, then act accordingly.

This means that there is all of a sudden a "right constraint" - and it shouldn't move.

Add capacity to all steps that should not be the constraint to ensure the Constraint doesn't starve!

10 - Plan for idle time

While Lean optimization would call out for idle time as a waste, we need to reverse that thinking. 

A machine can easily be planned for maximum utilization. We can easily calculate upfront how many items a factory can produce per day, per month - and even a year ahead of time. We can then set up our plant in a way that we have just enough capacity to produce just enough output just in time.

Humans don't tick that way. Knowledge work is unpredictable. People can't spend 100% of their time focused on churning out output ... Something unexpected always comes up, whatever - you name it: "The high probability of low probability events" makes it impossible to predict accurately. And the last thing you'd want is 20 people not being able to work, just because one person isn't available - hence: the need to ensure the Constraint doesn't generate flow blockage!

The best way to make decent forecasts is to ensure that the deliberate Constraint doesn't get into an Overburden state even when an unexpected event happens: 

As counter-intuitive as it seems: the Constraint needs to be the opposite of a bottleneck - it must have excess capacity!

11 - Feed the Constraint

The step that feeds the Constraint should provide a buffer that is both small enough as not to accumulate blockage - and big enough to ensure the Constraint doesn't starve, i.e. become idle.

Provide a constant, sufficiently big stream of inflow of work for the Constraint to ensure the Constraint never runs fully idle - as that would reduce throughput.

A deliberate misappropriation of  dimensions - the step that feeds the Constraint must be able to do so!

Bonus - Change your mindset!

A common misunderstanding in Kanban is to have "Doing", "Done" columns for each step of the process. This presumes that "my work is done, someone else's problem now".

When we stop focusing on the runners and start looking at the baton, i.e. when we observe the flow of work instead of the efficiency of each activity, we can't maintain this kind of thinking.

A work item that is "work in progress" is, by the very definition of the word, "progress" never done. Either it's "in processing" or "waiting for further processing" (i.e. "not done"). 

Therefore, it's quite important to banish the term "Done" from all buffers in the process, because it supports the wrong mindset!

We need to understand that there is no "Analysis Done, Development Done, Testing Done" - only "waiting for Development, waiting for Testing, waiting for Deployment". And all of these "waiting for" columns kill our flow efficiency. Unlike traditional Kanban, where it's good to have low Column WIP and getting items into the "Activity Done" column as fast as possible is an aspirable goal, flow efficiency re-defines the goal: we don't want any buffer columns at all!

The one in front of the Constraint is inevitable, but all other buffer columns are actually problems asking to be solved!