I know very well that Waterfall is largely thought of as an obsolete or passé approach to software development – something to be left buried back in the 90s. I also know full well that modern projects are huge, complex, and flexible in ways that we couldn’t have dreamed of back when Waterfall was all the rage.
I’m also a big proponent of agile methodology. I love its zen-like approach to software development. I’ve seen first-hand what a good Scrum Master can accomplish. So, no, I’m not here to tell you that Agile is bad or to compare the two.
In many ways, Agile rose as an answer to Waterfall culture, not the methodology per se, but rather, the stubborn notion that it was the be-all and end-all of software development. It was a response to project managers who assumed the principles of Waterfall as a gospel when in truth they were guidelines to solve a perceived problem.
Waterfall was a solution that was successful at the time, giving structure to the chaotic process of large-scale software development. But, was it perfect? Nothing is, but it was good enough that it became the default approach for a long time. If anything, Waterfall is still going strong.
Let’s take a look at the facts. According to the Project Management Institute survey from 2017, over 37% of completed projects used Waterfall as their method of choice, making it the most used methodology for project management worldwide. If we take into account the 20% that reported hybrid methods, then over half the surveyed projects use Waterfall in some form or another – hardly the numbers of a dying technology.
So, should you follow the masses and adopt Waterfall as a methodology? Well, if the answer was a mere yes or no we wouldn’t be having this conversation.
Defining Waterfall frameworks
At its most basic, Waterfall is an approach to software development that’s sequential and discrete. Teams are expected to follow a set of strict phases that start with requirement gathering and finish with the delivery and maintenance of the project.
We call it sequential because phases form a sequence of steps that have to be transited in a specific order, like water falling from a waterfall. There is no going back, there are no detours and no quick exits.
Each phase is discrete in that they are independent of one another (or at least as independent as possible) and that phase can’t start unless the previous steps are finished. You can’t start testing your work until the system design and your implementation is done.
While there is a bit of variation, most Waterfall frameworks have the same basic steps:
Requirement gathering: The team gathers information about the nature of the project, for example, expected features, the type of data it’s going to work with, and the environment where it’s going to be deployed, among others.
System Design: The team formulates a plan of approach and makes strategic decisions, for example, what technologies will be used for the project.
Implementation: The team starts working on the project based on their design choices.
Testing: The team runs a prototype of the project and checks for bugs or errors.
Delivery/deployment: The project goes live and it’s delivered to the owner.
Maintenance: The team provides support and fixes bugs reported by the users.
Keep in mind that while this may seem rather rigid, there is a bit of leeway. For example, the team may go back to system design to rethink their approach, or go back to implementation and work on the project depending on the nature of the errors found while testing. Of course, the idea is to avoid that kind of backtracking as much as possible.
Waterfall frameworks and you
To figure out if Waterfall is the right fit for you, first, you have to understand its strengths and how they solve certain kinds of problems better than other methods.
Waterfall methodologies use a very clear structure, which may drive developers mad, but for clients or coworkers from other areas is a lot more palatable and easy to digest. For example, it’s easier to justify a budget when you have a clear goal and a timetable.
Therefore if your project involves external investment, has to be approved by other departments, or will influence other areas in unexpected ways, a Waterfall approach tends to be more appealing to people outside the project. Tasks seem more organized and are easier to explain.
Since requirements are defined early on and remain constant throughout the process, Waterfall frameworks set very clear goals from the beginning and dissuade teams from deviating too much from them.
Small projects and small teams have a lot to gain from a focused approach. Projects are finished faster and developers are less prone to spend resources and time on secondary features that may not be fundamental for the product. If your team is small and your projects are predictable, then Waterfall could provide the ideal framework.
Waterfall is highly methodical, so, it should come as no surprise that the framework emphasizes very clear communication procedures in each step.
Since each process is carefully documented, it’s easier to share information between those different teams handling different stages of the development process. Also, new members can go through the documentation and catch up faster with the project.
If you think that your team may change at some point or that you might end adding new members, then Waterfall provides a good communication framework to keep everyone in the loop.
While it’s hard to predict group behavior, new teams often have to struggle with getting to know each other and understanding their workflow. Rigid frameworks like Waterfall create work routines that are easier to establish and negotiate, facilitating teamwork, at least in the early stages of the project.
Finally, Agile requires a certain management overhead that not every project manager is trained to handle. The notion of project management is quite different in Agile than what we are used to.
As such, Waterfall, for all its quirk might be an easier methodology to grasp and manage for a newcomer – unless you have a manager that’s trained in agile, or if your team has a project manager that’s not software developer.
In the end, no 2 projects are cut from the same cloth. Therefore, thinking that a single methodology can be a solution to whatever problem you are facing is hopeful at best and naive at worst.
A thoughtful approach to software development that helps you diagnose the nature of your problem is key to choosing the right methodology for your project. It’s not a matter of what’s popular, it’s a matter of what works.
