“Flow when you can, pull when you must.” Don Reinertsen. Author of Product Development Flow: 2nd Generation Lean Product Development.
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
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 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 code 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 to Delays
Most delays have a cause. In fact, about a decade ago I postulated what I now call “Shalloway’s law of delay and process.” It states that all harmful delays are caused by a process problem. The inverse of this, of course, means that if we fix the problem we’ll fix the delay (unless we cause another problem).
Shortening, or even avoiding, delays is accomplished by:
- Having smaller batches of work by using MBIs, MVPs and MVRs
- Keep work within capacity
- Having a well defined and managed intake process
- Increasing visibility of work so that people can see what’s headed their way
- Organize people so that there are fewer hand offs and interruptions (this can include dynamic mobbing)
- Use test-first methods
- Have quality code
- Use automated testing
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 work. 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.
I call these different levels of flow:
- program flow (flow through a group of teams without attending to the teams themselves
- inter team flow (flow between the teams)
- intra-team flow (flow within a team)
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 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 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 have to interrupt the developers to fix them. Not only does this delay cause extra work for the developer to find the work, the interruption 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 (see 1st comment if not familiar with this term)
- 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.