What Is Flow?

Flow is the ability to produce value continuously.

“Flow when you can, pull when you must.” Common Lean mantra.

Don Reinertsen says “A flow-based process delivers information on a regular cadence in small batches. In fact, cadence helps lower transaction costs and makes small batches more economically feasible.” He also suggests the best measure for flow is reducing the cost of delay – what the delays in value realized cost in terms of lower revenues, opportunities lost and higher risk.

Flow is the ability to produce value continuously. “Flow thinking” is using a collection of principles that can reasonably predict when an action will have a positive or negative impact on flow. The real challenge is not in knowing what to do but in getting people to do it. If you look at your system as having an intake and output, then one can think of achieving flow as a combination of having smaller batches of useful work, reducing delays and avoiding creating waste. Flow is usually not about going faster at any one step. The exception is when accomplished through automation. Attempting to get people to do their job faster likely results in a lowering of quality. We do not advise this.

Ideally, we’d have no handoffs. Unfortunately, this is not practical in many places nor even possible when some people are the experts in one part of the value stream and others are the experts in another. The easiest way to work with Flow is to look at what slows us down and then remove those items if they are on a critical path.

Impediments to Flow

There are many potential impediments to flow:

Working on things of lesser value defers us from working on the most valuable items. This delays value realization regardless of how efficient the development group is. This is another reason to use minimum business increments (MBIs).
Hand offs always result in lost information and therefore always reduces flow. Hand offs done without direct communication (i.e., writing a document and passing it along) are particularly insidious. Not only is there a delay caused by the writing and waiting until it is read, the quality of the communication degrades as well.
Interruptions to workflow break a person’s train of thought. This is especially pernicious for developers who, when they come back to what they were doing, have to recreate where they were in their mind.
Interruptions caused by changing what is to be worked on. The introduction of new work that was not scheduled causes interruptions to workflow, increases the level of work (often beyond people’s capacity) and creates new work to get back to where they were before the interruption.
Interruptions to workflow due to people not being available can cause considerable multi-tasking and setting aside work.
Slow feedback occurs when people aren’t working together or are working in the wrong order. For example, very often developers write code before truly understanding the requirements. Late feedback also causes interruptions when testers are not working in sync with developers, or different teams are not continuously integrating across the team (this type of integration provides feedback that the two teams are in sync with each other).
Delays in the time from getting information and using it means the information is stale by the time it is used. Doing requirements too soon is an example of this.
Long manual processes refer both to having to search through code to make changes (this is usually due to high technical debt) and to manual testing at any level.
Needed information arriving later than it would have been useful ends up surprising people and often has them unprepared for work. It is common for ops to be told requests later than they should have been even though it was apparent they would need to be involved. This also includes information that never gets where it should. This often causes duplication of learning.
Information being created prior to its need often requires the information to be refreshed. Hence, the “just in time” mantra.
Poor product quality either in terms of value to the customer or the robustness of the design. Delivering poor product quality to the customer delays delivering high quality. If our product is also built poorly, it is likely to break and take more time fixing. At a minimum it will be hard to change.
Rework requires doing additional, unplanned, work.
Doing duplicate work. Teams often duplicate work that other teams are doing because they are not aware of other teams’ efforts or don’t know how to avoid the duplication when small differences are present.

Causes of Impediments to Flow

You should observe that many of the impediments to flow revolve around delays or cause delays. Therefore, we can gain insights into improving flow by looking at how to reduce delays. It is also important to realize that delays are not just bad because they directly affect delivery times but because they create additional work. People often point to multi-tasking as the problem here but there is something far far worse. Delays of the sort mentioned above almost always cause additional work:

Working on larger batches of work than is necessary. This delays feedback, usually requires interruptions and increases work in process. Often reducing batch size is all it takes to bring a system back into control – Eli Goldratt, this observation is quite powerful. All of the above are affected by the size of the work. Another reason that managing work around MBIs is so important.
Slow feedback often results from large batches of work. It is a disaster both for product requirements and for development. In the case of product requirements, a lot of work can be done before discovering that the wrong thing was built. The time between code and test causes a large increase in the time to find the problem whereas if feedback were immediate this time would be minimal.
Long manual processes essentially act like interruptions in workflow.
Poor quality delays making changes as well as risks adding new errors. It also introduces unplanned work which makes it harder for people on different teams to collaborate.
Delays in providing information often delays release which can have a ripple effect on other items depending upon this release.
Working beyond the development group’s capacity tends to cause interruptions and delays.

The Cure for Delays

Most harmful delays are caused by problems in the process. If we can fix the process problem, we will often fix the delay (unless it cases another problem).

The Accelerate Value Delivery process goal offers options for reducing, avoiding, or eliminating delays. The aim of the Accelerate Value Delivery process goal is to optimize aspects of how our team works. As a result, this process goal encompasses critical decision points around work organization, deployment, configuration management, and quality assurance (QA).

Strategies to remove delays include:

Reducing batch sizes using MBIs, MVPs and MVRs.
Focus on finishing existing work so that the customers of that work do not need to wait for it.
Keeping work within the capacity of the team.
Borrowing a team member to bring more capacity onto the team.
Helping a team member to complete that task that you are waiting on.
Utilizing existing talents of people to perform the work that is delaying you.
Making workflow visible to help identify the cause of delays and to let people see what is coming their way.
Reducing work in progress (WIP) to lower the chance of having to wait for something to be finished.
Removing handoffs, thereby removing a source of delays.
Removing handbacks, thereby removing the need to wait for work to be fixed.
Having a well-defined and managed intake process.

In software, these techniques are also helpful in addressing delays.

Use test-first methods.
Have quality code.
Use automated testing.

Attend to the Levels of Flow

Very often, we begin by thinking about flow across areas of the value stream, from start to end of the value stream. This is good but it is not enough. In knowledge work, flow is happening at many different levels, wherever people are working together. We want to attend to flow at all of these levels.

Program flow. This is the flow through a group of teams without attending to the teams themselves. Program flow attends to what the program is working on. This often involves a large batch being worked on.
Inter-team flow. This is flow between teams. Inter-team flow attends to the flow between the teams that are working together. This provides much more insight on the delays present. It also provides insights into how the teams should work together.
Intra-team flow. This is flow within a team. Intra-team flow attends to all of the little handoffs and delays in the workflow of an item. For example, when programmers finish their coding and start working on something else even though the testers have not completed their testing; when errors are discovered, the developers have to interrupt their work to fix them. This results in a delay in flow.

Improving flow requires a persistent, intentional focus. We have to become “flow whisperers” constantly looking for ways to improve across all of the levels. Here are two helpful mantras to guide this work.

Minimize the cost of delay (deliver the most value quickly).
Flow when you can, pull when you must (avoid handoffs and focus on what’s most important).

Why It’s Better to Focus on Removing Delays Instead of Eliminating Waste

A common mantra from lean is “eliminate waste.” But this can easily become a red herring – that is, a distraction. Eliminate waste came from manufacturing where you it was both clear what the waste was and you could readily see it. Typically, waste in a manufacturing line is anything that doesn’t add value to the customer. But this is not true in knowledge work. Many activities that speed up the value add are necessary in knowledge work where not everything is known.

Waste in knowledge work can be considered anything that doesn’t add value to the customer and doesn’t speed up delivery of value to the customer. But there are still other variables such as “what is value to the customer.” In a manufacturing line that’s already been set, but in knowledge work most of our effort is on deciding what this is.

Focusing on the delays mentioned in this chapter, however, will always eliminate true waste as well as speed the realization of value to the customer.

Flow and Lean-Thinking

Flow and Lean-Thinking are interrelated but not the same. At a first cut one can think of flow as what we want to achieve, Flow-Thinking as how we look at flow and Lean-Thinking as how we achieve flow. Flow-thinking tells us to remove handoffs, use kanban, and work with smaller batches while removing delays. Lean-Thinking provides us with more ‘how.’. This includes a systems-thinking approach, management being responsible for setting up an environment within which flow can occur, a focus on quality and a model for learning. The two together are very synergistic.

Levels of Flow

When most people think of flow, they think of flow across areas of the value stream. While we consider flow from the start to the end of the value stream there are different levels of it to attend to. For example, when multiple teams work together, as in an Agile Release Train (ART) in SAFe^®, flow is being looked at at the program level. But within that, how teams work together is also important. We should also look at how people inside a team collaborate. All too often people presume that teams doing Scrum and/or Kanban don’t have any gaps in their work, but they do. A common one is delays between programmers finishing and testers finishing.

We call these different levels of flow:

Program flow. This is the flow through a group of teams without attending to the teams themselves. Program flow attends to what the program is working on. This often involves a large batch (called a program increment in SAFe^®) being worked on.
Inter-team flow. This is flow between teams. Inter-team flow attends to the flow between the teams that are working together. This provides much more insight on the delays present. It also provides insights into how the teams should work together.
Intra-team flow. This is flow within a team. Intra-team flow attends to all little handoffs and delays in the workflow of an item. A common occurrence of this is when programmers finish their coding and move on even while the testers have not completed their testing. When testers find errors, they must interrupt the developers to fix them. Not only does this delay cause extra work for the developer to find the issue, it also impacts the work being interrupted.

Why Attending to these Different Levels of Flow is so Important

Most projects are late because of a series of small, cascading errors. A half-hour delay in one place can cause 1 or 2 half hour delays elsewhere. These, of course, cascade to other areas. You must attend to all levels of flow to avoid this

Being a ‘Flow Whisperer’

Getting people to work together may be difficult. Knowing whether what you are doing is moving you in the right direction isn’t. There are two mantras to follow:

Minimize cost of delay (deliver the most value quickly).
Flow when you can, pull when you must (avoid handoffs and focus on what’s most important).

The first deals with working on the right things, the second working on them the right way. Both are implemented by:

Using Minimum Business Increments.
Organize your team to lower handoffs and queues.
Have a workflow that provides feedback up front (test-first).

Not attending to these makes a difficult challenge even more difficult. Driving from these avoids people working at odds with each other through lack of visibility and misalignment.

November 2022