Waterfall Methodology is Dead? Long Live Waterfall!

The introduction of new methodologies such as Agile or Kanban led to Waterfall methodology diving in popularity. Some might say, a dive to its death.

A linear approach to project management no longer seemed viable when considering the nimble, iterative approach taken by the others. Working in sprints to complete prioritized tasks and get customer feedback after each phase seemed a better approach than working in isolation to achieve project goals.

Yet, despite many teams adopting the more fluid approaches and touting its death, Waterfall does still have its place in some applications.

The logical nature of waterfall methodology has its advantages when it comes to project management in software development, and as a result, remains a useful approach for certain types of projects with specific particularities.

What is the Waterfall methodology?

Introduced first in 1970, by Dr. Winston W. Royce, the Waterfall methodology is a software development process, emphasizing the logical progression of steps to be taken throughout the software development life cycle (SDLC). The development process is often likened to the cascading steps down an incremental waterfall.

When it comes to project management, the Waterfall model serves the purpose of organizing the workflow of software development through a series of distinctive phases. It takes a linear management approach where customer requirements are gathered at the start, and a sequential plan is then created to meet these. The next phase can only begin once the current one is completed.

When the Waterfall model is successfully implemented, the development will flow seamlessly downward (similar to a waterfall), through several stages. These typically range in number from 5 to 7 phases:

Requirement Analysis

In this first step, detailed requirements of the software system that will be developed will be gathered from the client and stakeholders. These will be written down to define what the application should do, and will serve as the basis for all future development.

System Design

In this step, the programming language needs to be planned, for example, PHP, Java, .net. Databases should also be decided upon, such as Oracle, MySQL, etc. Other high-level technical details of the project should also be planned.

Implementation

After the planning and designing stages, the software is built. This is when the code gets written and all requirements laid out in the previous phases should be implemented.

System Testing / Validation

In this stage, the software will need to be tested to confirm that it has been built as per the exact specifications detailed by the client. Beta testers and other testers need to systemically identify and report on bugs and issues within the application.

Deployment

In this step, the application will be deployed into the respective live environment. The client receives their product and checks that it is in line with their requirements laid out in the beginning.

Maintenance

Once everything has been tested and successfully integrated, the client may request further changes that can be coded in at their request. During this phase, the application is live and being used while the team performs any necessary changes or work.

When to use the Waterfall Methodology?

There are many scenarios where the Waterfall model can be used, including when:

Client requirements are not frequently changing
The application is not big or complicated
Requirements are specified and clear
The project itself is short or has a specific time framework
The development environment is stable
Resources are adequately trained and available
The necessary tools and techniques used are stable, and not dynamic

Why Waterfall Methodology Became Unmodern?

When developing new software, finding the right methodology is key. Though many developers are moving to new and emerging approaches, Waterfall is still widely used in traditional organizational environments and processes. Research shows that 51% of organizations still use Waterfall, based on a 2017 report from the Project Management Institute.

Despite the Waterfall methodology being very structured and straightforward, making it suitable for many product teams, some drawbacks render this methodology outdated.

Defined requirements decrease room for creativity

By defining the overall requirements at the start of the project, this limits the product owner’s ability to utilize the various opportunities that may pop up during the development process.

In some cases, these opportunities could be vital to effectively adjust the requirements to provide a better solution. Waterfall projects are highly integrated and do not feature an object-oriented approach. This is another key aspect that can reduce overall creativity and flexibility.

The Waterfall methodology can be more costly

Even though stakeholders may be confident that they know exactly what they require, their needs may change throughout the development process.

Alternatively, they may not have taken certain changes into account at the start of the development process. By defining the requirements, in the beginning, this makes adjusting to new changes more difficult and overall more costly.

Making significant changes after everything has been built will require expensive reworks. For this reason, the design must be carefully be written with attention to every detail before going too far.

Any bugs that are written early on in the project can create massive problems for later code. The problem here is that none of those bugs will become apparent until testing begins. This makes fixing that code time consuming and very costly.

Requirements can easily be misinterpreted

In any working environment, it is normal for different people to interpret things in different ways. The relationship between the development team and product owner can become adversarial when one of the team member’s interpretations of the overall requirements comes into question. Keep in mind that very often, clients can be unsure of what they want at the start of the project, which will also have effects later on in the process.

A lot of effort is put in the documentation, not building the product

In the Waterfall methodology, all requirements must be completely documented and approved before any development can occur. This means that a fair majority of the work is done before moving onto the building phase, and can either be beneficial or detrimental to the project’s success.

Difficult to apply the Waterfall methodology to larger, more complex projects

According to Royce’s paper, Waterfall is ideal for smaller, internal projects but is generally quite flawed when it comes to larger, more complex projects. This method is also not suitable for other longer-term projects.

Why Do Companies Still Choose To Use The Waterfall Methodology?

Though many may see Waterfall as a slightly out-dated technology, many product developers stand by it. These are some benefits of the implementation of Waterfall methodologies, which include the following:

It is a simple and quite straightforward approach
It is easy to develop an overall plan for managing a Waterfall project because every phase has a specific start and end. This allows the team to ascertain exactly what coding is to be developed, when it’s due and when testing should begin. This can all be done before the commencement of the project
Early planning will ensure a solid basis for designing components that can seamlessly integrate with external systems
Planning resources for Waterfall is generally easier as you know exactly when everything will start and end
Clients who prefer specific start and end dates will appreciate Waterfall as this model allows them to know the exact date when they will have their product in their hands
The development costs can be determined before the project starts
Extremely detailed procedures can be used effectively to regulate all parts of the project, preventing any errors from occurring during the building process
A suitable solution for clients who prefer not to be involved in the development process and simply want to be involved in the beginning and then receive a complete product at the end
Ideal for small projects, where the speed of delivery is not of utmost importance
Situations where similar projects will be carried out in the future, allowing the project plan to be reused, making use of the heavy documentation that was drawn up previously

Conclusion

The waterfall is still effective for certain projects that are set within a constrained timeline or budget. Furthermore, the methodology narrows the focus to give a more complete understanding of all software deliverables, setting expectations from the beginning. The stage gates between each phase also ensure that each phase is complete before moving on to the next, and there is little client interaction which could cause delays throughout development.

Ultimately, however, the scope of the project, as well as client requirements, will factor heavily into which project management methodology is best for an application.