Despite the fact that for a very long time, it completely dominated the world of software development, today, it is difficult to find anyone who would rise in stalwart defence of the rusting Waterfall model. This comes down to a variety of factors, but above all, software companies have started to realise that in a fast-paced and ever-evolving world, it is not the old familiar, but agility that holds the answer.
So what exactly is Waterfall approach and why are so many businesses so keen to move away from it?
A breakdown of tasks into linear sequential phases
Similar to workflows that are used in the manufacturing industry, in the Waterfall approach, the entire development life cycle is divided into separate phases:
- Conception
- Initiation
- Analysis
- Design
- Construction
- Testing
- Implementation
- Maintenance
As the output of one phase serves as the input of the next, any of the above stages will only be given the go-ahead once the previous point in development has appropriately been completed.
The obvious disadvantage, of course, is that by making each stage so heavily reliant upon the previous one, Waterfall leaves very little room for catering to dynamic needs. Other drawbacks, however, include any or all of the following:
The main problems of the Waterfall methodology
1. Prone to serious misunderstandings
Because the development method is so dependent on a project’s requirements, if these are not accurately documented or a crucial misunderstanding persists, things could very quickly take a seriously pear-shaped turn. In other words, once a project has been green-lit, the only possible way to avoid a potentially costly car crash is to slam on the breaks and stop development altogether.
2. Inflexible
While Agile development offers us a quick working version of the project’s core functionality (the minimum viable product) which empowers the customer to prioritise requirements by consulting with end users, in Waterfall, all project requirements must be handed over in advance. As a result, should any circumstances change — and without the understanding of what exactly end users require — customers will be barred from altering their own products as they see fit.
This means that change management may also become significantly more complicated, as project stakeholders or project management must either roll back the project to the relevant previous stages or wait until all phases have been completed before beginning the cycle again (a process which could take months).
3. Unpredictable
With Waterfall, testing takes place at the very end of the project. In this way, if bugs have been created early on, finding them may at this point be essentially an impossibility. This, however, is never the case with Agile, as testing occurs frequently and throughout the entire process. Not only does this ensure that bugs are dealt with forthwith, but it also makes it viable to deliver fully shippable products.
4. Limits customer involvement
In contrast with Agile, which sees the customer as a vital part of the team and takes their feedback into account at every step of the product’s development, Waterfall projects are typified by very little customer involvement. In fact, after just a short time period when requirements are being actively gathered — and clients must inevitably be summoned — developers are once again in full command of the rudderless ship.
So, how bad is Waterfall development?
Of course, the Waterfall model is not the root of all evil either. Not only is it rarely used in its purest, most detrimental form, it also comes in a variety of different flavours that, to varying degrees, can improve upon the original (e.g. the “sashimi model,” which includes Waterfall with overlapping phases, Waterfall with subprojects and incremental Waterfall).
From time to time, it may also be necessary to run a project through isolated stages. If, for instance, each phase had to be delivered by independent suppliers or vendors and it would otherwise be extremely difficult to establish effective interaction between them — or even adequate communication.
Another possible scenario relates to our own experience working with corporate clients. Because these larger companies will usually have longer decision making and approval procedures, they are often wedded to their stages. For this reason, such businesses tend to do well with so-called “Wagile” hybrids — which make use of Agile methodologies like Scrum to accomplish individual phases.
Given the choice, however, at SPG, we will always remain Agile at heart. Our company is a strong supporter of the Agile manifesto and we proudly uphold its amaranthine values:
- Individuals and Interactions over processes and tools.
- Working Software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to Change over following a plan
When the Waterfall Model Makes Sense
Despite its criticisms, the Waterfall model is sometimes mandated by customer requirements. Additionally, there are scenarios where this methodology is chosen by us voluntarily. Typically, this happens with projects that have a limited scope. For example, developing a proof-of-concept with crystal clear input parameters and well-defined expected results can benefit from the Waterfall model’s uninterrupted cycle. In such cases, the linear progression provides a straightforward path to achieving specific goals without the need for iterative feedback and adjustments.
