Summary

Research evidence Data shows that iterative and evolutionary development is correlated with lower risk, higher productivity, and lower defect rates than waterfall projects.

Early large project evidence Major and life-critical systems have been developed iteratively rather than using the waterfall. Examples include the USA Space Shuttle flight control software, developed in 17 iterations, and the new Canadian air traffic control system. In the 1970s, the IBM Federal Systems Division conceived and widely applied the method Integration Engineering, an iterative lifecycle process.

Standards-body evidence In the 1980s the USA Department of Defense promoted a waterfall lifecycle in DOD-STD-2167. It was associated with high failure rates. In 1987 a recommendation was made to prefer iterative and evolutionary methods. This occurred in 1994 with the adoption of MIL-STD-498. NATO, the FDA, and other bodies have similar stories.

Expert thought leader evidence Many prominent software engineering thought leaders have recommended avoiding the waterfall and adopting iterative development, including Harlan Mills, Frederick Brooks, Barry Boehm, James Martin, Tom DeMarco, Ed Yourdon, and more.

Business case Iterative development is correlated with lower failure rates; the opposite is true of the waterfall. Each year, 23% of projects, averaging $1.1 million USD, fail. A two-year ROI analysis of investing $100,000 in iterative skills transfer could show an NPV of $700,000 with IRR of 200%.

Waterfall problems The original "waterfall paper" was misinterpreted and seldom read, its author actually endorsed iterative and evolutionary development, the waterfall was associated with high risks, and the creator of the waterfall DOD-STD-2167 standard retrospectively says he would have promoted an iterative rather than waterfall lifecycle.

Why still waterfall promotion? There are at least seven reasons why the waterfall continued to be promoted, including lack of awareness of the growing evidence that it was not ideal, its simple definition, and the allure of simple progress tracking (such as "requirements complete").

The remainder of the chapter is detail behind the summaries.

Exhaustive data can make for exhausting reading :-) This chapter is probably best spot-read as a reference.