Welcome to episode five of our series "The Seven Wastes of Software Development." In episode one, we introduced the concept of eliminating waste from our software development efforts. Waste elimination can be traced all the way back to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System (TPS). This is how Taiichi Ohno, the father of the TPS, described its essence:

All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes. [1]

In this episode, I'd like to focus on "Delays." Simply put, delays are anything that either delay the start of a value adding activity or that make a value adding activity take longer than it should.

Read the other parts in this series:

• The Seven Wastes of Software Development - Introduction
• Waste #1 - Partially Done Work
• Waste #2 - Extra Features
• Waste #3 - Relearning
• Waste #4 - Handoffs
• Waste #5 - Delays
• Waste #6 - Task Switching
• Waste #7 - Defects

Here are some common manifestations of delays in software development:

1. Starting development work on a project long after the initial customer contact or requirements gathering activities;
2. Waiting for appropriate staffing to become available to start working on a project;
3. Lengthy requirements documentation phases that attempt to exhaustively specify every aspect of a project;
4. Review or approval processes that act as gates between development process phases and that require the attention of a scarcely available individual;
5. Increased work in progress. Think about what happens on the freeway at rush hour. The more cars you try to shove onto the road, the slower the flow of traffic becomes;
6. Gaps between the completion of development work and the beginning of QA/verification work;
7. Gaps between the completion of verification work and the beginning of deployment.

Any of these delays will create serious problems in any software development environment, and each of them are pandemic.

Unlike the wastes we've looked at previously (partially done work, extra features, relearning, handoffs), there isn't really a process improvement spectrum around delays. Delays either exist, or they don't. Your goal is simply to eliminate them.

So why are delays so bad? Two primary reasons:

1. Delays prevent your customer from realizing value as soon as possible. Even if you remove all non-value adding activities from your process, any delay between the remaining value-adding activities adds no value. In fact, it can even have a net-negative affect on value if the delay reduces your customer's competitive advantage, profit margin, etc.
2. Delays introduce discontinuity into your process, and just as Type O blood is the universal donor type, discontinuity is the universal waste creator. Discontinuity always spawns instances of the other wastes:

   • Delays trigger task switching. If you don't have all of the knowledge that you need to complete your task, and you have to wait for that knowledge, then you can either sit idle or switch to another task. Either way, you're task switching and you've lost flow.

   • By triggering task switching, delays trigger partially done work.
   • Delays fuel relearning by lengthening feedback loops. Requirements that are gathered far in advance of development become obsolete and must be regathered. Defects that lie undetected in a QA wait queue force relearning as developers swap the related knowledge back in to address them.
   • In the same way, delays fuel extra features through those same lengthened feedback loops. It's quite possible that, given long delays between product demos, that we'll build to completion features that the customer no longer needs nor wants.
   • Delays between coding and testing, be it at the unit or acceptance level, increase the impact of defects by allowing them to lie undetected longer.

So what are some ways that we can attack delays?

Build complete project teams. Ensure that all of the individuals possessing all of the knowledge necessary to carry the project to a successful delivery have skin in the project game.
To the best of your ability, ensure that your teams are collocated. Face-to-face communication is the most effective means for sharing knowledge within a project team, and even teams separated by only an elevator ride or stair climb will have less face-to-face interaction. Get all of the project team in the same room if at all possible.
Use short timeboxed iterations and deliver value to the customer at regular intervals.
Seek out regular feedback, even in the middle of an iteration, and act on it immediately.
Ensure that knowledge is always made available at the timeliest moment. Don't make it available too soon, or it will become obsolete. Don't make it available too late, or its value will be negated.

That's all for this episode of "The Seven Wastes of Software Development." Stay tuned for the next installment: Task Switching.

References

[1] Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.