The Cost of Delay’s Many Faces
Traditionally in business management, the Cost of Delay is something that is calculated based on how much revenue would have been gained, or how many new customers acquired, if this feature or product could have gone to market X many days sooner.
Yet there are other kinds of Cost of Delay lurking in your organization. Look at it this way. You hired a plumber to fix your sink. She set aside up to 3 hours for you. Now imagine that once she gets to your house, you find out that your bathtub drain is also clogged and you ask her to see if she can fix that too. The plumber starts working on the sink first. While the plumber is waiting for the glue to dry on the pipe she reassembled, you ask her to go look at the bathtub drain. She spends an hour working on the drain, but the work is not quite complete. She then returns to the sink and begins to reassemble it. It is 3PM now and she has to leave for another appointment. So she tells you that she will need to come back tomorrow to finish the sink and the bathtub drain.
It turns out that if she had just 30 more minutes she would have been able to finish the sink. But she spent that time on the drain, and now she has to go. The Cost of Delay here is that you can’t use your sink or your bathtub until she fixes it tomorrow. Starting several projects at once because there is a belief that there may be downtime actually creates this type of Cost of Delay.
When we think about lean product development, the Cost of Delay is twofold. In Lean & Agile development, preventing the Cost of Delay is critical to the success of the learning and iteration process. Delay weakens the power of the feedback loop. The longer it takes to finish a feature and release it to users, the longer it will take to learn from it and be able to iterate on it effectively. The pillars of Agile are Transparency, Inspection and Adaptation. The sooner you can inspect is the sooner you can adapt.
The distraction of multi-tasking itself also leads to delay. While it may feel productive to have a team work on a number of things at the same time, there is usually a tradeoff in terms of time to production. If the team is working on only one goal, they may be able to ship that feature in two weeks. But if you add another feature alongside the first one, you will no longer ship that original feature in two weeks.
The distraction of a competing goal disrupts velocity more than it would seem. In fact it may be that you will not be able to deploy that original feature until 5 or 6 weeks later. The Cost of Delay here may be the traditional one, where revenue or customers are lost. It may also be an organizational cost in terms of resourcing, or it may be the delay of the agile feedback loop.
Most of the time the Cost of Delay outweighs any perceived benefit of multi-tasking. Our culture is conditioned to believe that busy = productive, when in fact that is actually the exception not the rule. But this is something that you have to experience for yourself to believe. As a start, begin to identify and acknowledge the Cost of Delay in your projects and your organization. It will allow you to see the actual trade-offs that you have been making.
