Jan21
In order to shine, a hero needs a dragon to slay.
Similarly, Agile methodology is often explained by contrasting it with the rigidity of the Waterfall model.
The Waterfall model is a process for Systems Development Life Cycle, focused on project management and solution design. It is characterized by highly planned, specification-driven development.
As possibly the first formalized model of this kind, Waterfall significantly influenced subsequent software development methodologies.
Waterfall is conventionally portrayed as a rigid, linear process with isolated phases. It is typically criticized for minimal or no involvement of stakeholders after the requirements phase, and a lack of flexibility in adapting to changing requirements.
Several historical factors contributed to shaping "Waterfall" into what it was.
Early computing limitations: during the 1950s and 1960s, computing was limited to mainframes with capabilities far below today's standards.
Lack of modern development tools: functionalities such as code-highlighting, IDEs, and version control systems were not even thinkable at a time when input and output happened on a paper-based interface.
Cost of computing resources: in the mid-20th century, computing resources were exceedingly expensive compared to labour costs, leading to a preference for manual analysis and testing, and minimized computing time.
Complexity of projects: computing resources were uncommon, and therefore reserved to large projects, colossal in scale and complexity, and therefore necessitating meticulous coordination.
Considering these factors, it is clearly important for a development model to have maximum consideration for the use of computing resources, and anticipate the resolution of errors as much as possible.
The Waterfall model is commonly attributed to Herbert D. Bennington's 1956 paper and Winston W. Royce's 1970 paper. The adoption of a Waterfall-like methodology by the US Department of Defense in 1985 (DOD Standard 2167) is often blamed for popularizing a rigid version of Waterfall.
However, neither Bennington nor Royce used the term Waterfall in their papers, nor did they advocate a rigid process, and the same can be said for the DOD.
Royce's paper actually presented a nuanced view. He endorsed a basic model with iterative relationships between development phases. Furthermore, Royce proposed five enhancements to this basic model, one of which was continuous customer involvement - a key aspect that Agile methodologies are known for promoting.
Already in the early 1980s, anecdotal evidence began to emerge about sales practices dismissing the outdated waterfall model as something no organization should ever use. This was according to Professor David Dischave, who, despite having spent 20 years in IT application development across five major corporations, had never heard of such a model before.
Myth: each phase must be completed to 100% and its results frozen before moving to the next one.
Reality: iterative features were part of the model from its inception, as shown in Royce's original diagrams, portraying an iterative relationship between development phases.
Myth: end-user involvement is ignored outside of requirements specification.
Reality: the Waterfall model does not exclude customer involvement after the requirements phase. In fact, the model, as originally described by Royce, includes provisions for iteration and continuous customer input, and advocates the introduction of a prototyping stage.
Myth: waterfall means setting impossible deadlines, that are decided before really knowing what the project is about.
Reality: all three main sources indicate that there will be changes needed even after a software program goes into operations. All three state that there is significant unpredictability in developing software. Benington, in particular, reflects on lessons learned and advocates an iterative approach, estimating a potential reduction of overall time by 50%.
Myth: too much time passes between the collection of requirements and the receipt of feedback from end users, often resulting in requirements that are no longer relevant at the time of delivery.
Reality: this is an issue of scope, rather than methodology. Nothing in the Waterfall concept prevents chunking the business needs into smaller pieces, and delivering those smaller chunks rapidly as multiple, iterative efforts.
The rigid version of Waterfall that is commonly criticized today seems to be a misinterpretation of the original papers. This version lacks a clear origin, but it has become ubiquitous and conveniently supports the narrative of big-"A"-agile. It suggests the notion that transitioning to Agile is a monumental effort, necessitating a dramatic shift in corporate culture. And, of course, a hero.
Dragon stories, while fascinating and inspiring, do not provide a practical foundation for developing wildlife management practices. Similarly, organizational change should not rely on misinterpretations of the significance of the 'fossils' retrieved from an old methodology.
This article owes most of its content to the analysis done by David Olson in his article THE MYTH OF THE 'WATERFALL' SLDC
Further sources (also quoted in Olson's article):
Research Paper - Production of Large Computer Programs, by Herbert D. Bennington. From a presentation at a symposium on advanced programming methods for digital computers sponsored by the Navy Mathematical Computing Advisory Panel and the Office of Naval Research in June 1956
Research Paper: Managing the Development of Large Software Systems, by Dr. Winston W. Royce, 1970
The waterfall – A Historical View to Organizing Software Development. By Patrik Malmquist. 5 September 2011
Research Paper: Toxic Concepts in Systems Analysis and Design: The Systems Development Lifecycle. By Paul Ralph. May 2010
Research Paper: A Review of Risk Management in Different Software Development Methodologies. By Hijazi, Khdour, and Alarabeyyat. May 2012
Article: A Waterfall Systems Development Methodology … Seriously? By David Dischave. On the Global Enterprise Technology web site. 17 September 2012.
By Fabio Turel
Keywords: Agile, Project Management, IT Strategy