Using the Theory of Flow to Find Your Impediments

This chapter is a continuation of the What is flow? chapter.  If you haven’t read that (short) chapter, please read it before continuing as you’ll get more value from this one if you do..

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. lack of visibility as to why something is important
  5. “ghost work” (i.e., work that’s not seen by anyone other than those doing it)
  6. many handoffs taking place
  7. requirements being defined by mostly product folks and then handing them off to developers
  8. developers writing code on their own and then handing it of to testers
  9. lack of automated testing

Looking for delays and what we can do about them

Figure 1 is presented to provide a place to identify where delays commonly are present.

Figure 1: The ideal value stream

Let’s now look through the ideal value stream for delays and what’s causing them in each of the main areas.

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?

Planning

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?

Release

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

Common practices to solve common challenges

Most of the challenges above can be solved with a combination of the following practices:

Strategic planning & Lean Portfolio Management

  • Use OKRs (objectives and key results) to use as the basis for your strategies, initiatives and definition of business increments. This creates visibility on what the organization is working towards. Also, the OKRs can be weighted by importance and used to normalize MBIs/MVPs/MVRs across different business stakeholders.
  • Work with product management when they define MBIs, MVPs, and MVRs.
  • Plan quarterly. This helps creating smaller batches of work thereby enhancing the ability to pivot.
  • Think in terms of long-lasting products and services not in terms of projects to allow for reasonably stable teams.

Lean Product Management and Intake Process

  • Use MBIs, MVPs and MVRs. This creates smaller batches, which as Eli Goldratt says “are sometimes all it takes to bring a system back into control.”
  • Create and manage a well-defined intake process. This enables using pull to manage work levels as well as create visibility on what is to be worked on.
  • Create well defined acceptance criteria for all backlog items

Planning

  • Have planning events be primarily about collaboration and dependency management
  • Have teams pull work from the backlogs created

Implementation and Integration

  • Have teams be as cross-functional as possible.
  • Use mob-programming when appropriate
  • Use dynamic mobbing when appropriate (see this article on dynamic feature teams)
  • Keep work within capacity by using a pull system when handoffs are needed
  • Make interruptions visible and work towards eliminated them
  • Have teams be directed by one product owner
  • Use test-first methods
  • Automate all acceptance tests
  • Automate unit tests
  • Improve code quality
  • have cycle time of stories be 3 days or less

Release

  • Ensure all work is visible to ops as soon as possible
  • Include all tasks necessary to realize value when an item is released are included in MBIs, MVPs, and MVRs