The Waterfall methodology was named after its sequential phases arranged in a downward fashion (similar to actual waterfalls), representing the various steps of software development from one end to the other. It was published in 1970 by the computer scientist Winston Walker Royce, and it originally contemplated five distinct phases: requirements, design, implementation, verification and maintenance.
Some variations of the original model emerged in the following decades, but the logic behind Waterfall remained the same. When a phase is completed, its output becomes the input for the next one, which starts immediately after the former. It contemplates all the essential points that compose software development, and its simplicity made it very easy to understand and adopt immediately.
Waterfall ensures that each phase is completed before moving on to the next one. The reason? To avoid starting development before the design work is completed, which could give way to possible incongruities in both ends. Additionally, it is possible to estimate the whole project's cost and effort needed right from the start in the requirements phase through this model.
While the Waterfall model was far from being the only possible approach to software development, it was not until 2001 that it experienced a fundamental paradigm shift. What caused it? Agile software development.
The principles of incremental software development were already being used through different scattered processes. Still, it was only in 2001 with the Manifesto for Agile Software Development, that Agile software development (as we know) was introduced and popularised. This very straightforward document, put together by a group of developers in Utah, surely broke the conventions and limitations of software development, providing a real alternative to the Waterfall method.
Above stands a perfect example of what Agile aims to be. The various cycles - conventionally named sprints - seek to cumulatively deliver value, being part of a bigger picture that leads to project completion. That is where it differs the most from the Waterfall method.
Agile seeks to be more flexible, allowing regular increments and minimising the time needed for planning by focusing on shorter timeboxes. Each iteration adds value to the product and provides working software as it concludes, planning the nearest step in more detail than the others that will follow.
Different subsets adopt Agile as a philosophy, similar to what happened with the variations of Waterfall. DSDM (Dynamic Systems Development Method), FDD (Feature-Driven Development), XP (Extreme Programming) and, probably the most popular, Scrum, all draw from Agile to execute software development processes.
Regardless of different opinions, it is a fact that Agile changed how software developers decided their approach to new projects. Knowing what each methodology represented, what did this mean to Waterfall?
Almost as many people say that Waterfall is dead as those who say that Agile is an insignificant trend. There's nothing wrong with having different opinions, but let's get down to the facts here:
The Stack Overflow survey pictured above shows how Agile is, undoubtedly, the leading choice for software developers. Besides being the first choice used by 85.4.9% of the community, the popular subset Scrum takes the second place with 62.7%. Further down, Waterfall can be found in the sixth place, with 15.1% usage.
At first glance, it does not look good for Waterfall. We can clearly state that Agile is the most popular method, and there's no way to argue against those numbers. However, it's a mistake to ignore such a high percentage of developers who use Waterfall. We wouldn't say, as an analogy, that Huawei is an irrelevant brand because it has just 14.6% of market share in the mobile phone industry, behind Apple and Samsung.
However, it is a fact that Agile exposed a few weaknesses and flaws of the Waterfall model by pointing out how hard it is to fix issues in previous phases and how it takes a whole process to have working software. All this with a high amount of uncertainty in between.
As the message spread, it became cool to be Agile, everyone wanted a piece of it, and all processes became Agile as a consequence. No one is bragging about their Waterfall processes. From marketing and economics to software design and development, every business wants everyone to know that they are Agile, even if they don't know themselves what it means. That's what is causing the whole fallacy supporting the argument that Waterfall is now irrelevant.
Everyone seems to be missing the point: neither Waterfall is dead nor Agile is the universally superior methodology for software development. Adopting one over the other for the sake of being better is just an illusion that often masks the inexistence of a proper process.
Waterfall is definitely the best pick for stable projects since heavy planning is done initially, counting on all aspects (both internal and external) that can influence the project's execution. Regardless of the project's dimension, Waterfall is the most suitable choice when the external environment is stable and unlikely to suffer changes throughout the plan.
For these types of projects, Waterfall was the best approach before Agile entered the picture, and it still is as today. If you can plan a project ahead in a low risk envorionment, there's no real benefit in splitting it into several sprints to deliver value each week. It is best to focus on the end result right away.
Alternatively, Agile is the way to go for projects that require a more flexible process, given their unstable and unpredictable nature. In other words, if the product vision and respective can change due to external factors (e.g. market dynamics, etc), then it is better to build and adapt the product using Agile. It's also the best method to ensure that the project does not stay in development for several months before presenting any result. By the end of each sprint, there'll be a checkpoint in which the product owner can test and approve the completed work.
In changeable projects that adopt Waterfall, the lack of proper checkpoints creates risk since it's harder to fix possible issues found by the end of development. The extra time allocated for planning the whole project does not ensure that the design and development phases will run smoothly until the end, as most issues are as undesired as unpredictable.
Choosing either Waterfall vs Agile should be more than just a marketing move. It should consider all the aspects that can influence a project and how well-defined a priori a product is. Picking the wrong tool for the job could lead to extra costs of time and effort.
Each software development challenge has its particularities and, usually, the requirements phase in any method is the point at which the cards are laid on the table. However, before jumping right into action, there are a few questions regarding the nature of the project you should know.
Methods such as Waterfall and Agile exist as different approaches to solve variations of the same problems. Depending on their particularities, several projects may be better developed and more suitable with either one or the other.
All in all, why do we prefer Agile to Waterfall? Given what we have seen up until now, hopefully, we're all past explanations such as "Waterfall is dead, long live Agile." As a general rule, one is not better than the other and, most times, it's a mistake to think otherwise. We have tried Waterfall for a long time, and made the shift to Agile when - given the nature of most of our projects - we found it to be the top pick.
In our Agile Development Process, we adopted a Scrum methodology, a subset of Agile, and made a few adjustments to meet our clients' specific needs. We find this to be the better option for our projects since we contemplate both the possibility of ending it with an MVP (Minimum Viable Product) - which would fall under the Proof of Concept phase - or go further through a set of sprints that will add incremental value to the product.
Once again, it would be a mistake to think that this is the best possible process to adopt in every project, and that is the reason why we review and adapt it to suit our needs when necessary. That's what led us to move from Waterfall to Agile in the first place, and if needed, further improvements will be made. However, it is never a question of creating universal solutions, as such a concept will never exist in software development.
It's crystal clear that Waterfall is not dead, and Agile is not the best pick perse. That's the easier way to look at it and the most dangerous way of handling software development. It all comes down to your specific needs and the best way to meet the desired ends. Any further discussion about it creates unnecessary noise.
What has been happening over the last few years is that being Agile is seen as a perk. A notable characteristic that a business can get associated with that instantly proves its quality. It is neither everyone is Agile, nor no one knows what Agile is. Still, all the commotion makes it harder for anyone to truly understand what methodologies like Waterfall and Agile are all about.
The best way to go beyond looks and actually make a difference with a software development process is to truly understand each project's needs, pick the method that suits it best and adapt accordingly.
Content manager, text editor, and presenter of strategic ideas, along with being an avid fan of the cinematic arts and visual storytelling.
People who read this post, also found these interesting:
.png)
