Here are some conditions that can tell us when to use Waterfall as a software development methodology.

For all of us that work in the software industry, it is not strange that Waterfall methodology has fallen into disuse – even hated by some – following the introduction of Agile methodologies that have stepped into the market.

The new wave was then and still is now, without a doubt, immersing in Agile’s sweetness. So why look back?

Being faithful to my own need to take sides with the evil characters in films or comics (Darth Vader, Cersei Lannister, Wile E. Coyote, or Dick Dastardly), in this opportunity, I want to illustrate a defense on the unpopular Waterfall methodology.

After more than a decade of participating in software projects, working with both Agile and Waterfall methodologies, viewing their results and achievements from up close, and being a witness of how software industry methodologies have evolved, I have decided that it was time to talk about a few cases where its use is possible and beneficial.

That being said, based on my personal experience in the software industry, I will point out some conditions that can tell us when to use Waterfall as a software development methodology.

1.      Depending on the client

Software development is a service, and like every service, client focus is fundamental. The following are some situations that can indicate that the best option for your project is to choose Waterfall.

• When the client knows what they want: Even though it may seem impossible, there are clients that are very certain about what they want. Also, many times, you might be working with the client for a while, which helps the development company know how they work. As for the client, they also know the potential that the hired company can offer them.

Having an established relationship between both parts makes it feasible to perform a good survey of their needs, while at the same time having professionals who possess all the knowledge regarding the problem’s context and their own experience. In these situations, it is very possible that Waterfall methodology adapts smoothly to the project and helps avoid some likely bad habits from Agile methodology.

• When the client cannot participate actively in the development: There are situations where the client is unable to be an active participant throughout the whole development process.

Given this situation, the development company can choose to carry out a more rigid methodology like Waterfall. A key factor when working with Agile methodologies is active participation and communication of every single part involved. Therefore, taking on an Agile methodology when it is not possible to count on the client’s feedback may lead to wasting highly valuable time or ending up in unnecessary meetings and repeated processes.

• When the client needs it: Sometimes, due to the development company’s conditions and context, it may be hard to take on another methodology other than Waterfall. This is the particular case of projects where deadlines and documentation must be fine-grained delivered before the development begins, or when due to quality certification issues or regulatory compliance, the client must adhere to certain structures and times.

2.      Depending on the cost, time, and functionality

In fixed price contracts where time, costs, and functionalities have been previously determined, Waterfall methodology is a suitable alternative.

As project administrators, the software development company is obligated to create a budget so that the project does not lead to losses. While Sprints can improve quality, they can also be expensive and can divert the estimated budget.

Having a set time will lead us to choose a more rigorous structure like Waterfall, which does not contemplate deviations or improvised changes. In closed projects, with a fixed and well-defined functionality, this methodology helps reduce the margin of error.

Waterfall framework was conceived for projects with fixed costs, time, and functionalities. However, while such a state of perfection will never be achieved, the truth is whenever we are dealing with this type of scenario, considering using Waterfall would be more convenient.

3.      Depending on the planning we need to do

Being that Waterfall planning is simpler, direct, and less participative, it is possible to know at which time all different people involved in the project will come into the scene. This offers predictability, better time planning (especially for those who have multiple occupations), and ease of coordination.

For example, functional analysts are strongly involved during the system’s definitions stage, but as time goes by and development continually advances, their participation significantly decreases. The same thing happens with the client, who can get involved in the definition stage as much as the approval stage with no need to be in the intermediate stages. As for developers, they can join after the analysis stage, and testers can do it close to the end when it is time to perform tests.

There are cases where different teams simultaneously take action in all development stages (including teams from other companies). Here is where Waterfall methodology helps make work organization simpler. Eventually, and if they decide so, each team will internally use whichever methodology is the most helpful for their daily job.

To Sum Up

The purpose of this information is not to make a comparison or argue against Agile methodologies, but to focus on pointing out a few factors that may help decide whether it is right and convenient to choose the ’old school’ Waterfall framework for a software development project.

While it is true that the balance has been tilted for some time by the development of Agile methodologies, the reality is that we cannot ignore all the attributes Waterfall can offer us when we develop applications and solutions.

Far from remaining in disuse, even in this Agile era, Waterfall is a framework that allows us control over time and budget, while helping us to anticipate the solution’s scope and make accurate estimations. So, why shouldn’t we use it when all conditions are met?

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.