Disciplined Agile

Why Looking at Delays in the Value Stream Is So Important

Table of Contents

In Principles of Product Development Flow, Don Reinertsen states, “if you only measure one thing, measure cost of delay.” We measure so we can try to eliminate delays. Delays not just in value realization, but in anything that directly or indirectly causes delays in value realization. 

These include:

  • Delays in workflow (typically due to waiting for people or due to handoffs)
  • Delays in feedback after a decision or activity
  • Delays in realizing value
  • Delays in knowledge transfer

These all not only delay value delivered but they literally increase the amount of work to be done. Lowering them is critical and can be done by:

  • Managing queues
  • Having small batches
  • Creating visibility
  • Automating testing
  • Having a test-first attitude at acceptance and unit level


Why Looking at Delays Is So Important

Ideally, all of the work being done in a value stream is “value-added work” for the product or service we are creating. The reality is that some percentage of the work being done is due to problems and delays in the workflow. It is work that we have made for ourselves beyond what is required to accomplish our goals. It happens at all levels and scales of the organization. We call this kind of work, “induced work.” Work that we bring about on ourselves. It is waste.

If we can identify delays and remove them, we can “stop creating waste” (at least some of it). This reduces the overall time needed to finish our creative work, so we become more productive. It leads to a virtuous cycle where many other benefits follow, including higher quality, avoiding or fixing errors quickly, and gaining a better understanding of features so that even less work is wasted.

We find delays by looking at where time is spent in the process.

Delays Reveal Loss… and Opportunity

Waste: Hiding in Plain Sight

digImagine two people working next to each other digging holes. Neither person is aware of the other. The first is shoveling dirt into the second's hole, creating more and more work. That is a lot of waste? How would you go about eliminating this waste? Stop the first person from shoveling without regard for the second!

How often we fail to recognize we are creating the waste we need to eliminate. And when you are down in the trenches, it can be hard to see it.

The first digger may not even be aware of causing waste. If you told her to eliminate waste, she might just think, “what waste?” and keep on digging. The second digger does not know there is “useful” dirt to be removed and “waste” dirt that was just thrown in. There is just dirt and it has to be removed. It seems like there is a lot of it.

The diggers lack the perspective to see what they are doing. Waste can only be seen when we look up, look from outside of the problem.

Lean thinking helps you look up. 

Unfortunately, as in this case, we often don’t realize we are creating the waste we need to eliminate. In this example, to the ditch digger in the foreground, there is just dirt in his hole that he has to remove. There is not the “useful” dirt that was there that he has to remove and the “waste” dirt that was thrown in by the other ditch digger. There is just dirt.

Note also that the other ditch digger isn’t aware of the extra work he is causing. In other words, if you told these folks to “eliminate waste” they’d probably just shrug their shoulders, think “what waste?” and get on with doing what they are doing. Waste often can only be seen when one looks from outside the problem. Yet another example of why an holistic approach is required.


“Eliminate Waste” or “Stop Creating It”?

Rather than “eliminate waste,” it is more useful to “stop creating waste.” Because all too often, half of our work involves digging out dirt that has been put into our hole by another group. Lean suggests that the way forward is to focus on eliminating delays in the workflow rather than trying to do work faster.

For example, consider the challenge of dealing with bugs in software development. A developer writes a bug. Now imagine that they are told about it immediately. How long does it take to fix? Let’s say an hour. Now, imagine that they aren’t told about this for a couple of weeks and further imagine that nothing else has changed. How long does fixing take now? A lot longer, maybe even days longer. And it gets even worse if more code has been written since the bug was created. It gets worse and worse.

That bug is induced work. Waste that we have created.

Here are some examples of induced work.

  • Re-doing requirements
  • Working from old requirements
  • Building the wrong feature
  • Building unneeded features
  • “fixing” bugs (most of the time is spent on finding them)
  • Overbuilding frameworks
  • “Integration errors” (they are really errors resulting from two groups being out of synch)
  • Essentially duplicating components

Let’s look at these in a bit more depth.

Re-doing requirements or working from old requirements is caused by the delay between when you received the requirement and when you needed to use it. Building the wrong feature is usually due to a miscommunication between the customer (or their proxy) and the development team. The greater the delay between getting the initial requirement and actually building it will increase the amount of work involved.

Building unneeded features is caused by failing to learn in time what is really needed. If we focus on building the most important features in small batches (a classic lean approach), we can use what we learned to see if we actually need the pieces we deferred. This accelerates value delivery while shortening delays to feedback. And that reduces induced work.

We have already addressed the delay caused by fixing bugs.

Overbuilding frameworks and essentially duplicating components are often caused by a lack of skill in design patterns and emergent design. They also arise when developers forget or fail to know what have already been done.

Integration errors are rare. They do occur but more often than not, the integration error is caused by an error that occurred well before integration: teams not staying in sync with their code, components that do not work together properly even though each one integrates correctly. The error happened earlier, it was just caught at the time of integration. And that delay in detection is waste. It is induced work. As it happens, this is why continuous integration is so helpful in addressing this issue. It is not about avoiding integration errors, it is about detecting miscommunications between groups working together as they occur. 

Reflect on this list of induced work. Much of it could be addressed by reducing delays in the workflow. Catching them earlier. Improving communication. That is how you reduce or eliminate induced work. 



Much of the work we do is actually not making progress on our goals but is literally induced (created) by the delays in our workflow. Lean suggests that we look at the delays between our workflow in order to eliminate the waste created by these delays. While we should also be looking how to improve our work, our biggest initial returns are likely going to be by attending to time.

Related Resources