Disciplined Agile

Using the Theory of Flow to Find Your Impediments

The best way to measure the impact of delays is reflected in Don Reinertsen’s mantra – “If you quantify one thing, quantify the cost of delay.” When making a decision on a workflow improvement experiment, we can gauge its potential effectiveness by anticipating what will happen to our cost of delay. We can then see what actually happens to see if we got an improvement or not.

A side note on predictability. It has been in vogue to talk about unpredictability in the Agile space. It is true that we often have a large degree of unpredictability in what is needed. This is the value of using an empirical process in determining what will provide value and delivering it. But it is a misconception to believe that our process cannot be founded on a well-defined and explicit theory. Flow thinking is such a theory.  Throughout this book we have described how large batches, lack of workload management, delays in workflow, delays in feedback, poor team organization and other factors contribute to delays which create additional work and which increase our cost of delay. Being aware of these relationships provides us a basis for making usually effective decisions on what to do. Of course, there is a large degree of unpredictability in the organization itself, so these decisions should always be considered hypotheses to try and validate.
Understanding the relationship between our process and where it contributes to the cost of delay is essential.  When we identify a challenge we can consider what practice changes have improved the challenge in the past. We can use the theory of flow to indicate which we should try for our situation. Because changes may have side effects outside of where the change is taking place we have to validate that the change is actually providing improvement. This is another reason for working on smaller pieces as it is usually easier to validate a workflow change when the work items are small. Very often, however, practices can be improved that do not require tradeoffs. For example, test-first methods are almost always beneficial.

Using flow theory as a guide enables us to focus directly on our challenges. Following the established practices of frameworks hopefully reduce delays when considering how they are used across all the companies that use them. Unfortunately, what works for another organization may not work for yours. So set practices are often not effective.

What to look for

While many things can contribute to delays, the following are the primary causes:

  1. large batches of work
  2. having too much work in process
  3. not having a well-defined and managed intake process
  4. seeing work going back and forth between people or teams
  5. lack of visibility as to why something is important
  6. “ghost work” (i.e., work that’s not seen by anyone other than those doing it)
  7. many handoffs taking place
  8. requirements being defined by mostly product folks and then handing them off to developers
  9. developers writing code on their own and then handing it of to testers
  10. lack of automated testing

Looking for delays and what we can do about them

Let’s now look through the ideal value stream for delays and what’s causing them in each of the main areas. Figure 1 is presented to provide a place to identify where delays commonly are present.

Strategic Planning & Lean Portfolio Management

Look for:

  • Too long a backlog of things to work on. If it’s more than one year to get it all done, there’s a good chance that half of it will be obsolete by the time you get to it
  • Is there visibility of how things are identified, selected and sequenced throughout the organization?
  • Are MBIs, MVPs and MVRs being used?
  • Is the corporate planning and budgeting cycle more than three months long?

Lean Product Management and Intake Process

Look for:

  • Are MBIs, MVPs and MVRs being used?
  • Is there a well-defined intake process?
  • Is there acceptance criteria for the backlog items?


Look for:

  • How teams are coordinating with each other
  • Is there a focus on building MBIs, MVPs and MVRs?
  • Are all four types of dependencies (technical, business, architectural, communication) being identified, made visible and tracked?
  • Implementation and Integration
  • How many handoffs are present?
  • How many interruptions are present and what/who causes them?
  • Is work being pushed to the teams?
  • Are teams being directed by more than one product owner?
  • Are teams working on too many things?
  • Is upstream work visible to the teams?
  • Is upstream work visible to the shared services?
  • Are test-first methods being used?
  • Is there automated testing?


  • Is ops being blindsided?
  • When things get released are they ready to provide value?

Related Resources