These days, speaking positively about waterfall software development may sound like singing the praises of beepers: Unless you’re still living in the 1990s, it’s easy to feel that the world has moved on.

In the case of software delivery, it has moved on to a landscape dominated by what’s known as agile development. In general, today’s developers see agile as a faster, more efficient and more scalable way to build and ship software. Much has already been written about agile delivery, yet there is hardly anyone nowadays enumerating the advantages of waterfall.

To a degree, this is not surprising. It’s true that agile is superior to waterfall in many respects.

Yet it would be a mistake to write off waterfall as being totally irrelevant today, as some developers seem to have done. There remain situations where waterfall makes more sense, so let’s explore them by highlighting the advantages of waterfall relative to agile delivery for modern organizations.

Agile Vs. waterfall: The key differences

Let’s start by briefly defining agile and waterfall, and identifying the main differences between them.

The agile methodology, which was popularized by the Agile Manifesto in 2001, emphasizes an adaptive and collaborative approach to software development. While there are no hard-and-fast rules or processes that teams have to follow to perform agile development, agile workflows center on the idea that developers should be prepared to modify software features and release schedules as needs change. Agile also prioritizes frequent, incremental changes to an application rather than introducing a slew of new updates in a single release.

In contrast, the waterfall development methodology breaks software development cycles into relatively long and rigid phases. Teams identify the features they want to implement in an application, implement them and release them, working hard along the way to stick to the original plan. This approach tends to result in application updates that occur relatively infrequently (typically, no more than a few times a year) but that introduce major change when they do take place. In other words, each new release is like a waterfall of changes that occur all at once — hence the waterfall methodology term.

The advantages of waterfall in an agile world

Again, the majority consensus today is that agile delivery is superior to waterfall delivery. By enabling developers to respond more quickly to changing business goals, while also providing more frequent software updates, agile supposedly benefits business stakeholders, programmers, and customers in equal measure.

It’s true that, for teams working within environments where goalposts constantly shift and customer expectations are hard to predict, agile has its advantages. Yet the waterfall methodology can be more beneficial than many teams realize, even in today’s world of continuous everything.

What teams can expect from waterfall

Predictability

With waterfall, what you plan is what you get (usually). In other words, the features that a development team commits to early on are what the team actually implements.

From a business perspective, this predictability can be highly valuable. It’s hard for managers, sales teams, marketers and support technicians to plan ahead when the application features that developers originally promise end up not fully materializing — as they may for teams that use an agile approach where plans can change with little notice.

Simpler management

Compared to agile, waterfall is usually much easier to manage. Rather than having to meet constantly to evaluate the state of each development sprint and make sure all stakeholders remain aware of rapidly shifting development plans, waterfall allows teams to make a plan and implement it in a straightforward fashion.

In this sense, waterfall can lead to more efficient use of development resources — provided, of course, that the plan that developers commit to initially is the right one (meaning it aligns properly with business requirements and is practical to implement).

Reduced risk of failed releases

The measured, steady pace of waterfall development means that there is typically a lower risk of pushing out problematic software updates.

In contrast, in an agile environment, teams are more likely to adopt a “fail forward” mindset, assuming that they can quickly correct issues with one release by pushing out another release.

That may be true. But bad releases waste a lot of time, while also causing a poor experience for users and harming the business’s reputation. There’s a good argument to be made that it’s better to invest heavily in carefully planning, implementing, and testing each release so that you don’t push out a bad one in the first place.

Smoother user experience

Agile is often presented as preferable for users because it allows them to receive software updates on a constant basis.

There is some merit to this argument. Users do benefit if they get critical new features every month, rather than having to wait a year or more for an important update.

However, what is often forgotten within this conversation is the fact that constantly barraging users with new features can degrade the user experience. If you change your app’s interface multiple times a month, for example, you may end up with confused and exasperated users who grow tired of having to adapt constantly to interface changes every time they log in.

Of course, waterfall brings its own challenges for users, who have to adjust to major app changes following each release. But new releases are fewer and farther between under the waterfall methodology, and developers can usually notify users ahead of time that a major change is on the way. That’s arguably better than the agile approach where teams continually spring updates on users with no warning.

Easier documentation

In an agile environment where plans and features are always in flux, it can be easy for developers to forget to document every new feature or significant code change they implement. That’s not so in the context of waterfall development, where slower release cycles and more consistent planning encourage better documentation practices.

If you’re worried about your team’s ability to document applications properly over the long term, then, waterfall may be a better approach. Agile could leave you with applications full of undocumented (or under-documented) features, which become hard to maintain when the developers who wrote them leave the company or simply forget which changes they made.

Sometimes, waterfall beats agile

To be sure, there are plenty of reasons to practice agile delivery, as a majority of teams now do. Yet to dismiss the waterfall methodology as an anachronism would be short-sighted. For developers and businesses that need predictability, consistency and minimal risk, nothing beats the waterfall approach.