What Is Flow?

This is an excerpt from Introducing FLEX – FLow for Enterprise Transformation: Going Beyond Lean and Agile (online book). If you are looking for an alternative to SAFe, this is it. To those who'd like to study along with me as I publish this on linkedin, please ask to join the True North Consortium Linkedin Group where I will be happy to answer any questions or, even more importantly, discuss things you disagree with in the book. See prior chapter on linkedin. See next chapter.

If you want to learn more about FLEX you can watch a webinar on FLEX, take an online course at the Net Objectives University or take a live course in Orange County, CA May 6-8 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

-----------------------------------

“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 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 being when it can be accomplished through automation. Attempting to get people to do their job faster likely results in a lowering of quality, and is not advised.

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.

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.

Hand offs reduce flow because information is always lost. 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 have to come back to work they were doing the state of which was in their head but now needs to be recreated.

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.

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. 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 clearly slows things down as additional work is now required.

Doing duplicate work. This is often done in implementation where different development teams are not aware of the duplication of efforts or don’t know how ot avoid it.

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.

Interruptions to workflow due to people not being available can cause considerable multi-tasking and setting aside work.

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

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.

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

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