Two big benefits of incremental delivery

Tarun Upadhyay wrote a fair criticism of our previous post on why incremental delivery is good on his blog today. It is great that he is extending the conversation, and he makes a couple valid points. We definitely missed a big benefit of incremental delivery, and will cover it in this post.

Here are the main points from Tarun’s critique:

The analysis is rather simplistic and does not assume any additional gains from having all four pieces working together (typical in many but not all projects) and also does not take into many other benefits from agile iterative releases like:
a) creating a release structure forces good habits like: continous integration, automated build management and consistent configuration across development, QA and production
b) many releases forces customer to see the product early which reduces surprises and produce better alignment around what customers want vs. what the team is developing
c) earlier releases brings out many feature requests from the customers earlier in the cycle (causing fewer design changes and less rework) reducing the overall costs.
d) estimates are better when deliveries are iterative.

We like incremental delivery. We don’t promote it because of the correlated benefits that often happen when we do incremental delivery. We promote incremental delivery because of the two big benefits that are caused by incremental delivery.

Two Big benefits

1. Achieve ROI faster from earlier deployment.
2. Higher absolute ROI from deployment of more valuable software.

Achieve ROI faster
Our previous post on why incremental delivery is good focused on this single benefit. By delivering independent, atomic sets of functionality as early as possible, we can begin getting ROI from the software faster than if we waited until the originally scoped software was complete to release it.

This chart shows ROI versus time for a simplified example of delivering the most valuable requirements first, prior to completion of the least valuable requirements.

Higher absolute ROI

We completely overlooked this other big benefit of incremental delivery in our previous post. A key premise of why agile methods are better is that we learn as we go. Once we start writing the software, we begin to learn more about it. Through iteration and prototyping we gain a better understanding of the requirements.

When we take advantage of that knowledge, we improve requirements (make them more valuable) and replace requirements (with more valuable requirements). Therefore the requirements that we ultimately implement are more valuable than the ones we initially identified. The result is that the absolute ROI will be higher when we use incremental delivery.

Tarun’s points b & c are also addressed here. He points out that it costs less to change the software before it is written than after it is written. The iteration and feedback cycles definitely give us this benefit. To his credit, the argument can be made this way. We believe the argument is more compelling when presented in terms of differential value than differential costs.

Other possible benefits

There are other sources of benefit, though marginal in comparison with the big benefits. These benefits, however, don’t come from incremental delivery, nor are they prevented with waterfall delivery. Teams that deliver incrementally tend to also have other beneficial processes. Introducing incremental delivery processes at your company may create a vehicle for making these other things happen, but they aren’t strictly required.

Lower cost of quality
The earlier we catch bugs, the less they cost to fix. We can take the same testing approach with both waterfall and incremental project plans, so assuming that incremental requires or forces better quality is wrong. It would also be wrong to say that a waterfall process prevents better quality. When comparing incremental delivery with alternative approaches, we have to isolate those things that must be different from those that might be different.

Think of it in terms of correlation and causality. Teams that deliver incrementally tend to have better processes – but that’s correlated, not causal.

The only difference that is caused by incremental delivery is that we get end-user bug reports earlier. These bugs might influence fewer users if our incremental releases are designed to have incrementally increased user-bases. With a smaller code base (at the time of bug-fixing), it might cost us less to fix the bugs that are reported in early releases.

Automated process steps are more efficient

Making the statement that incremental delivery process must be more efficient than waterfall process simply isn’t true. We’ve worked with teams that release new functionality every month with painfully manual build and test processes. A waterfall process may have nightly builds, automatically pulling the trunk from source control and running regression, performance and load tests every day on dedicated hardware. This type of development-process-enhancement can happen with or without incremental delivery schedules, and incremental deliveries can happen without these beneficial processes.

Improved estimation

Respectfully, we disagree.

Estimation improves when the estimator reviews previous estimates and gets better at providing estimates over time. This is a personal development process, and can be accomplished by any developer working on any project. There is nothing that prevents a waterfall project from reviewing estimates throughout the course of the project. Without the benefit of constraining a development team to timebox based delivery, incremental delivery is harder to estimate than waterfall delivery.

Incremental delivery is harder to estimate because we fully expect to change the scope of the project as we go. Individual task estimates can be updated in either process approach.

The benefit of waterfall process estimation is that we can confidently predict how long it will take us to implement the wrong requirements.

Summary

Incremental delivery is valuable because we get returns earlier, and by adapting to feedback from the early deliveries, we can improve the requirements resulting in higher absolute ROI.