The origins of the so-called “Waterfall” approach can be traced back to Winston Royce, a director at Lockheed Software Technology in the 1970s, and his now-famous paper from the 1970 IEEE proceedings, entitled “Managing the Development of Large Software Systems.” Although the term “waterfall” was not used in this paper, it was the first to describe the process that has come to be called “Waterfall”, due to its graphical representation depicting workflow trickling from one stage of the process to the next, reminiscent of an actual waterfall. Figure 5 shows Royce’s original depiction of the Waterfall process.

The Waterfall as an engineering approach is said to have probably first been applied on a large-scale project by IBM during the development of the System/360 operating system in the 1960s. (Cusumano & Smith 1995)

In a 2004 interview with Fred Brooks, director of the IBM System/360 project, he was asked “Have we learned anything about software development in 40 years?” His response was: “We’ve learned that the waterfall model of development has to be abandoned, and it hasn’t been yet. We need to adopt the spiral model …”

The waterfall process has the advantage of focusing early on complete requirements specification (getting it right the first time,) and since most software projects are said to suffer from poor requirements definition, this approach puts an emphasis on requirements. However, in reality requirements changes are unavoidable (“we might as well embrace it,” according to Agile practitioners) – The problem with the waterfall is that the cost of change is prohibitive, and very slow. This is because at the end of each phase, the outputs are certified (via formal inspection and verification) and become the inputs for the next phase. Team members are not supposed to change outputs that the project has already certified. (Cusumano & Smith 1995)

Much of the debate in software engineering related to Agile development frames the discussion in terms of “Waterfall vs. Agile.” This is not exactly an appropriate comparison. Waterfall simply describes a “stage-wise” model of development in stages (e.g. planning, analysis, implementation, test, deployment) whereas Agile describes project team performance and use of “agile methods” as we will elaborate in section 3. In other words, a software team can be Agile within a waterfall development model, and a Waterfall iteration can be used within an Agile project – However for simplicity in the context of this research we will continue to contrast Agile with Waterfall, with the term “Waterfall” being a placeholder for “traditional, stage-wise, complete design up-front, single-pass waterfall software engineering approach.”