It seems anecdotally accepted in many places in the literature that among software development methodology choices, Agile is better than “waterfall.” Agile enthusiasts often describe waterfall as rigid, wasteful, demoralizing, and old-fashioned. Rarely, if ever, do these writers provide supporting data for these reported qualities but rather, simply assume that these criticisms are accepted fact, then using them as a straw man against which Agile can be compared, not surprisingly conclude that Agile is the logical choice (see for example, this 2014 Oxagile blog post). Some critics have noted this lack of rigor and have denounced the use of the term “waterfall” as bogus (e.g., There’s no such thing as the Waterfall Approach!, A Waterfall Systems Development Methodology … Seriously?). So, where did this debate come from and what does it mean?
One of the earliest papers written about software development methodology that might be thought of as “waterfall” is the 1956 paper by Bennington in which he describes an approach for the production of large computer programs. The key feature of the method is its phased approach to creating the needed levels of understanding about the product in its creation. The phased approach allowed incremental gathering and consideration of constraints on the product, first resolving the logical requirements then the physical requirements. The phased approach was extended in the 1970 paper by Royce in which he advocated for the use of documented specifications at each phase as the primary means of communication. Finally, a 1976 article by Bell and Thayer attached the label “waterfall” to Royce’s approach while failing to note that they were referring to one of the facets of Royce’s argument and not his final method. Ironically, Bell & Thayer’s article spoke highly of Royce’s paper and offered additional improvements to his recommended approach in the form of rigorous quality control (QC) of documented specifications. Subsequent writers have compounded the error by misattributing both the method and label to Royce and turning Bell and Thayer’s supportive reference into a pejorative term.
There are a host of points to unpack about this sequence of events. All three publications were describing software development in the context of large software projects with broader program dependencies (air defense in Bennington’s and Bell & Thayer’s cases and space flight control in Royce’s) that were high-cost, low-risk tolerance applications. Both provided recommendations related to their context because of the hardware/software dependencies, expected large team size, high cost of computing, the unacceptable cost of failure, and other considerations. While monetary cost of computing is no longer a primary concern, some projects still face the other considerations (e.g., software-based airplane control). In those cases, phased projects, specification-based development, and rigorous QC of specifications are still appropriate choices. None of these authors was prescriptive about other types of software development and Royce acknowledges at the outset that small development projects need only contain 2 steps – analysis & coding.
The next point missed by Bell and Thayer is that the diagram they referenced in Royce’s paper was a brief nod to a hypothetical, linear phased approach which he immediately dismissed as being inaccurate, indicating that iteration between adjacent phases is both possible and usual. The core of Royce’s paper then discusses additional improvements to the model using documented specifications as the primary means of communication between phases and between team functions. Thus, the diagram that continues to be attributed to Royce as his “waterfall” model was intended to represent only a starting point or rhetorical framework for a discussion of actual practice and his improvements.
Waterfall variants like Royce’s prescribed approach, the Spiral model (1986), the V model (1991), the Sashimi model (1986), and others demonstrate flexibility not assumed by Agilists. In actual practice, project managers can iterate between successive phases, overlap phases, decompose products into components that could be phased separately, accept change requests then analyze the impacts and update plans accordingly, or iterate over the basic phased approach (see Iterative and Incremental Development: A Brief History).
Beginning with Royce’s paper, the waterfall model has always been a straw man for contrast to improved methods. But in using “waterfall” as a starting point, Agilists are ignoring 3 decades of subsequent methodology development and are using the same straw man that Royce used to motivate his own improvements as an early part of that 30-year history. These arguments are weakened by use of a long-outdated model as the point of comparison – sufficiently so that it raises the question, why not compare with contemporary plan-based approaches?
