SIGN UP FOR FREE | SIGN IN
Thinkers360

Unmasking the Myth: The True Tale of Waterfall vs. Agile

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.

What is Waterfall, exactly?

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.

The Waterfall model

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.

Historic perspective

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.

Origins of the Waterfall inefficiency myth

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.

Misconceptions of Waterfall

1. The frozen waterfall

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.

2. No feedback from users

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.

3. Unrealistic deadlines

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%.

4. Requirements becoming outdated

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.

Conclusion

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.

"Living dinosaurs did not inspire the dragon idea - they died out long before people were around to observe them. But the fossil remains of extinct animals have sometimes been taken for dragon bones--and helped perpetuate old dragon stories."

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.

References

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):

By Fabio Turel

Keywords: Agile, Project Management, IT Strategy

Share this article