What is waterfall methodology

What is Waterfall Methodology?

Waterfall is the old-school methodology of software development. However, companies throughout the industry still practice it. This article will explore the waterfall methodology and its shortcomings. The name Waterfall methodology comes from its linear approach to development, with each step flowing on from the previous one. These steps tend to be drawn in a waterfall pattern.

The typical steps in a waterfall project are:
  • Requirements Gathering
    All the requirements for the entire project are gathered in advance. This usually takes the form of one or many very large documents. Each document details in very low-level detail the entire system and every function it will perform. This is called the functional documentation.
  • Design
    Once the requirements for the project are delivered, then the architectural design can commence. The architect team usually produce many diagrams and more detailed documents describing how the requirements will be met. These are the technical specification documents.
  • Implementation
    Once the detailed functional documentation is complete and the detailed technical specification documents are written, then the development team starts to build the application.
  • Testing
    Once the development of the application is complete. The testing team then test the system and pass any bugs back to the software team to fix.
  • Delivery
    Once all the bugs are fixed, the software is then delivered back to the stakeholders.

In practice, this approach does not work very well for anything but the simplest of projects (projects taking less than 4 weeks).

The system breaks down due to the following:
  • Complexity of software
  • Length of time taken to deliver anything useful
  • Requirements change due to changing business environment or details which are uncovered in later stages of the process. (E.g. a developer finds out that the architects’ plan can’t work due to limitations in the coding language chosen).

Waterfall projects have the following side effects:

  • Slow pace of work to begin with, since everyone knows it is months or years before the deadline.
  • Huge rush and panic towards the end, as the deadline draws near.
  • Since testing is not done during development, the list of errors is usually huge and takes much more time than was allocated to testing. This causes the project to overrun or code that is not stable is released. This is compounded by the fact that testing comes at the end and if the project overruns, it is the first thing to get cut.
  • Change becomes a problem since the process doesn’t allow for going back to a previous phase. Any change causes the entire project to be re-estimated and re-scheduled. For this reason, the project team do everything they can to dissuade the business from making changes.
  • Since the business wants to make change, and the development team doesn’t, the development teams usually force the business through a long and costly change request process.
  • When the project is finally delivered, in most cases the functionality is no longer required, or the understanding of the original requirements has been lost along the way and the functionality wasn’t what was intended by the stakeholders. This is because there was no way for the stakeholders to check as the project proceeded.
  • The project is described in technological language which the stakeholders / business don’t understand. This causes disconnect between the project team and the stakeholders and errors due to translation.

A friendly warning

When you look for your next role, I strongly recommend you find out if the project you are going to be working on is run with a waterfall methodology or an agile one. If it is a waterfall one, I would recommend not taking the role.

Get certified!

Learn more about agile on our highly-impactful and certified agile training courses in London and online.

Finally, you might be interested in reading Project Type – Agile or Waterfall?

Leave a Comment

Your email address will not be published. Required fields are marked *