What Is Flow?

“Flow when you can, pull when you must.” Don Reinertsen. Author of Product Development Flow: 2nd Generation Lean Product Development.

Flow is the ability to produce value in a continuous manner. “Flow thinking” is using a collection of principles that can be used to reasonably predict when an action will have a positive or negative impact on flow. This, of course, assumes the action is actually done. 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 going faster and reducing delays. Going faster can be accomplished in several ways:

  1. Put smaller things in so it takes less time to get them out
  2. Do the work you do the same way, but only faster
  3. Do the work you do in a different way that is faster
  4. Focus  on removing delays in the workflow

The first one has several advantages and is one of the reasons I talk so much about using the right balance of minimum business increments (MBIs), MVPs, and minimum viable releases (MVRs). But trying to do the work you do now, but only faster, will likely result in a lowering of quality, and is not advised. The third method of going faster could include better collaboration through pairing or mobbing or through automation.

In addition to working on smaller things, the easiest way to achieve flow, however, is to remove what is reducing flow – delay. This is the essence of approach 4 above. There are several types of delay:

Working on things of lesser value.  While we may be able to do these efficiently, we’re slowing the development of things of greater value while doing them. This is another reason to use MBIs.

Handoffs reduce flow because information is always lost. Handoffs 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 due to people not being available can cause considerable multi-tasking and setting aside work.

Interruptions occur through the introduction of new work that was not scheduled as well as when people work beyond their capacity having to work on one task and then another before the first is completed.

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 synch with developers, or different teams are not continuously integrating across the team (this type of integration provides feedback that the two teams are in synch 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 refers 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.

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.

Delays cause additional work

Before looking to see how to avoid delays, it is important to realize that they 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:

Handoffs themselves require the work of the hand off but also require the person who got the information to learn something probably known by the person giving them the information

Interruptions to workflow break a person’s train of thought. This is especially pernicious for developers who have to come back to work they were doing the state of which was in their head but now needs to be recreated.

Slow feedback 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

Delays in the time from getting information and using it often requires the information to be refreshed.

Long manual processes essentially act like interruptions in workflow.

Poor code quality delays making changes as well as risks adding new errors.

Delays in providing information often delays release which can have a ripple effect on other items depending upon this release.

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).

Delays can be shortened, or avoided altogether 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 handoffs 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.

 

If you want to learn more about FLEX you can take an online course at the Net Objectives University or take a live course in Orange County, CA May 7-9 or in Seattle in June (both led by Al Shalloway). If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway