Does Waterfall deserve its bad press?

In recent years, there has been a tendency to equate the Waterfall methodology with ‘evil’ and the Agile variants as ‘good’.  Having worked on successful projects under Waterfall (and Agile for that matter) but also some Waterfall projects that failed spectacularly, I would argue that Waterfall still has its place in modern software development.  This post will make the case that disregarding Waterfall as an option for future projects is potentially setting more software projects up for failure than need be the case.

But wait, I’ve heard terrible things about Waterfall

There can be no disputing that Waterfall is not a sensible choice of methodology for all software projects.  It can be rigid, dogmatic and, in many cases, can lead to the development being delivered no longer being what is required.  Waterfall can make changing something already done extremely expensive and time-consuming.  It is effectively useless if the client or user is not clear on what exactly it is that they want.  Waterfall is also not suitable for projects where development needs to start quickly or where the intention is to release incremental improvements to get benefits soon.  However, for the right project Waterfall can provide a stable and sensible framework for the project’s management and execution.

So, what is it good for?

Some might say, “Absolutely nothing”.  However, they are mistaken.  Waterfall projects generally follow the same pattern of linear phases – Requirements definition, Design, Development, Testing and Implementation.  This linear and well-defined structure makes Waterfall a relatively easy methodology to implement.  The discrete phases also give several advantages for the right project.  From a project management point of view, the phases make it easier to provide more accurate estimation of timescales and budgets (although this is not fool-proof by any means).  With the bulk of the research and analysis completed in advance to define the requirements, it allows the project manager (and developer) to estimate the time required to develop and test each requirement more accurately.  This, in turn, can provide more reliable milestone and release dates.

The phases, and the output produced at the end of each phase, also provide natural points and evidence for reflection and progress measurement of the project.  These milestones allow the manager to compare the current situation to that planned and have potential slippage highlighted, and remedial action taken, as soon as possible.

The Waterfall method also allows a team to cope more effectively with resourcing issues such as a team member leaving the company or moving to another project.  This is a common risk for teams within large companies.  These companies tend to have several projects/clients at the same time and so resources can be regularly reallocated to other projects, depending on the current priorities.  As a result of Waterfall’s insistence on documenting each stage of the process and the project knowledge (e.g., Business Requirements Document, System Design Document), it is easier for a new developer (or analyst, architect or testing for that matter) to pick up work that has been left by a departing team member as the knowledge is retained within the team.  Within teams, Waterfall also means that it is easier to accommodate specialists or inexperience than some methodologies that demand that team members are knowledgable on all aspects of the development.  Under Waterfall, team members are generally responsible for one area, such as requirements, user interface or testing.

Finally, Waterfall is one of the most effective methodologies for distributed teams.  As a result of the documentation produced, the defined phases and individual responsibility for tasks, the necessity for continual communication within the team is reduced significantly.

The model also provides advantages to the client or user.  Firstly, the upfront analysis phases encourage projects to define a clear plan and vision prior to development.  This helps ensure that the focus is on the right areas and that the architecture is right before development starts. A further consequence of this focus on defining requirements and system design upfront is that it can help with the quality of the development because of the time spent analysing the development and any potential risks.

Waterfall can also be helpful to clients because they are not required to provide resources or staff throughout the project as in Agile.  Under Waterfall, before testing and implementation, the project team only needs access to clients/users during the early stages of the project and at the defined milestones.  This is relevant as many clients are reluctant to contract a project team to develop software, only to provide the team with the client’s own staff, thereby increasing the cost of the project to the client.  There is also the relative security of potentially more accurate budget and time estimates.  Many clients are reluctant to commit to (and assume the risk of) projects where accurate estimates cannot be given in advance and the risk of cost overrun is left open.

So, what type of projects are right for Waterfall?

Most obviously, projects where the requirements are stable and unlikely to change in any meaningful way are good candidates for Waterfall.  One example of this may be a development being carried out to ensure a company can remain compliant with new legislation.  In this case, the legislation and resulting requirements are likely to be set in stone.  The up-front analysis and design also makes Waterfall an option for projects that are large and complex.  There is a risk with some other methodologies that the ‘bigger picture’, particularly if complex, gets lost in amongst the focus on requirements that can be delivered in iterative phases.  Finally, Waterfall is also a natural option for projects to develop critical systems.  Critical systems often require each step of the project to be reviewed, analysed and/or approved by management or client experts.  Waterfall’s phases and corresponding output provide easy milestones for these actions to be carried out.

This post is not arguing that Waterfall is a panacea for all software projects.  It is evidently not.  As discussed, the model has numerous flaws and, for the wrong project, can prove disastrous.  However, Waterfall remains a relevant project methodology in today’s environment.  The current trend of dismissing it as an option for software projects may lead to more software project failures than would otherwise be the case if it was considered for the right projects.

Bibliography

Clark, A. (2014, February).  Software Development Methodologies.  SAPM.  Lecture conducted from University of Edinburgh.

Sommerville, I.  (2007).  Software Engineering.  Harlow, England: Addison Wesley

Mikoluk, K. (2013).  Agile vs Waterfall: Evaluating The Pros And Cons.  Udemy.com.  Retrieved 9 Feb 2014, from https://www.udemy.com/blog/agile-vs-waterfall/

Haughey, D. (2009).  Waterfall v Agile: How Should I Approach My Software Development Project?  ProjectSmart.com.  Retrieved 9 Feb 2014 from http://www.projectsmart.com/articles/waterfall-v-agile-how-should-i-approach-my-software-development-project.php

‘Melonfire’ (2006).  Understanding the Pros and Cons of the Waterfall Model of Software Development.  Techrepublic.com.  Retrieved 9 Feb 2014 from http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/

One thought on “Does Waterfall deserve its bad press?”

Comments are closed.