Waterfall versus Agile – comparing software development methodologies

One of the first decisions you need to make as a project manager before starting a project implementation is: Which development methodology should I use? There are several methodologies you can use to manage a project. This blog contains reasons and information about two methodologies which can help you make this decision.

What is Waterfall?


The Waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance. This means that when each of the eight stages are completed the developers move on to the next step. Once a step has been completed developers can’t go back to a previous step without reviewing the whole project and starting from the beginning. There is few room for changes or errors, so a project outcome and an extensive plan must be set in the beginning and then followed carefully.

What is Agile?


Instead of a sequential design process the Agile methodology follows an incremental team based approach. Developers start with a minimalistic project design, and then begin to work on small modules (sprints with a defined duration and a running list of deliverables planned one sprint in advance). The deliverables are prioritized by business value as determined by the customer. At the end of each sprint project priorities are evaluated and tests are run. These sprints allow bugs to be discovered in an early stage and customer feedback can easily be included into the design before the next sprint is run.

Comparison between Waterfall and Agile

In this picture you can see the differences between both methodologies at a glance.


Image source: Waterfall versus Agile

Advantages and disadvantages of both methodologies

Advantages Disadvantages
  • The customer knows what to expect in size, costs and timeline
  • Minimal impact in case of employee turnover due to strong documentation
  • Developers and customers agree on what will be delivered up front
  • Progress is more easily measured, as the full scope is known in advance
  • Team members can work on different projects simultaneously
  • Customer presence isn’t strictly required after the requirements phase
  • Makes it easier when multiple software components must be designed for integration with external systems due to early known design
  • Once a step has been completed, developers can’t easily go back to a previous stage and make changes
  • The initial requirements can’t be changed without heavy impact
  • Testing the whole product at the end is risky due to finding bugs in early written code
  • A customer’s evolving needs are not taken into account. When changes are demanded this will impact the deadlines and budget
  • Possibility of a dissatisfied customer with their delivered software product due to not seeing the product until it is almost finished
  • Value is added every sprint
  • Easier to add features that are up-to-date with the latest industry developments
  • Project priorities are set before every sprint and evaluated after each sprint
  • Customer feedback is allowed and will contribute to the final end product
  • Testing each sprint (also by the customer) ensures no surprises at the end
  • High level of customer involvement (strong sense of ownership)
  • Short time to market: quickly produce a basic version of working software
  • Transparency is high
  • Deviations on the final product can arise due to no existence of a definitive plan
  • Customers need to have the time for the high degree of involvement otherwise the product will not match their requirements
  • Additional sprints could be added due to added requirements, because not all these requirements are clear during the start of the sprints, this may increase costs for the customer
  • The iterative nature may lead to a reduction in overall system quality, as there is less emphasis on understanding the finished system as a whole early in the project


After putting the information together, what can we conclude from all this? Both methodologies have their own strengths and weaknesses. The choice of methodology really depends on the goals you want to achieve. This all comes down to the context of a project. In fact, will it not be better to combine aspects from both methodologies to make the best possible software development process for the project?

When should you use the Waterfall methodology?

  1. When customers will not have the ability to change the scope of the project once it has begun
  2. When a clear image of what the final product should be must be worked out in advance
  3. When definition and quality are the keys to success instead of fast delivery

When should you use the Agile methodology?

  1. When customers need to be able to change the scope of the project
  2. When there isn’t a clear picture of what the final product should look like
  3. When quick production is more important than the quality of the product
  4. When the product is intended for an industry with fast changing standards, like software development
  5. When you have skilled developers available who are adaptable and able to think independently

Ultimately, although the way in which you do your work is important, most important is delivering a solid and supportable product that satisfies the customer’s needs!


Leave a Reply

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