It is popular in some parts of the agile community to use Water Fall as the boggy man for all things wrong with the management of software projects. As one who works in the Software Intensive Systems domain on System of Systems programs, Waterfall is an approach that was removed from our guidance a decade and a half ago. But first some definitions from the people who actually invented waterfall, not those critical of the process and unlikely having accountability for showing up on time, on budget, on spec.
- Waterfall Approach: Development activities are performed in order, with possibly minor overlap, but with little or no iteration between activities. User needs are determined, requirements are defined, and the full system is designed, built, and tested for ultimate delivery at one point in time. A document-driven approach best suited for highly precedented systems with stable requirements.
- Incremental Approach: Determines user needs and defines the overall architecture, but then delivers the system in a series of increments (“software builds”). The first build incorporates a part of the total planned capabilities; the next build adds more capabilities, and so on, until the entire system is complete.
- Spiral Approach: A risk-driven controlled prototyping approach that develops prototypes early in the development process to specifically address risk areas followed by assessment of prototyping results and further determination of risk areas to prototype. Areas that are prototyped frequently include user requirements and algorithm performance. Prototyping continues until high risk areas are resolved and mitigated to an acceptable level.
- Evolutionary Approach: An approach that delivers capability in increments, recognizing up front the need for future capability improvements. The objective is to balance needs and available capability with resources and to put capability into the hands of the user quickly.
The first criticism of Waterfall came from Dr. Winston Royce, "Managing the Development of Large Software Systems," Proceedings. IEEE WESCON, August 1970. pages 1-9, Originally published by TRW. Notice in the paper design iterations.
Royce’s view of this model has been widely misinterpreted: he recommended that the model be applied after a significant prototyping phase that was used to first better understand the core technologies to be applied as well as the actual requirements that customers needed!
The DOD replaced Waterfall DOD-STD-2167 with MIL-STD-498
TRW (where Royce worked) was an early adopter of Iterative and Incremental Development (IID) originated by Dr. Barry Boehm in the mid 1980's. The first work in IID programs was taking place in the mid 1970s. A large and successful program using of IID at IBM Federal Systems Division was the USA Navy helicopter-ship system LAMPS. A 4-year 200 person-year effort involving millions of lines of code. This program was incrementally delivered in 45 time boxed iterations (1 month per iteration).
The project was successful: "Every one of those deliveries was on time and under budget" in, "Principles of Software Engineering," Harlan Mills, IBM Systems Journal, Vol 19, No 4, 1980. Where he says ...
The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. Key steps in the process were to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made along with adding new functional capabilities.
Many in the agile community use these words, perhaps without ever have read the 1980 description of how complex software intensive systems were developed at IBM FSD and TRW.
In 1976 Tom Glib stated:
"Evolution" is a technique for producing the appearance of stability. A complex system will be most successful if it is implemented in small steps and if each step has a clear measure of successful achievement as well as a "retreat" possibility to a previous successful step upon failure. You have the opportunity of receiving some feedback from the real world before throwing in all resources intended for a system, and you can correct possible design errors.
The Incremental Commitment Spiral Model is applied in Software Intensive Systems in the DOD. But agile development has entered the domain in 2014 with the connections between Earned Value Management and Agile Development.
Without an understanding of the history of development life cycles, many - most recently the #NoEstimates community - use Waterfall as the stalking horse for all things wrong with software development other than there approaches.
So when you hear the Red Herring Fallacy that Waterfall is the evil empire, ask if the person making that claim has done his homework, worked any Software Intensive System of Systems, or has experience being accountable for the delivery of mission critical, can't fail systems? Probably not. Just personal anecdotes yet again.
