Methodologies for Project Management: Waterfall vs. Agile

Methodologies for Project Management: Waterfall vs. Agile

Jonathan, a senior project manager at a large software company, held his head in his hands.

“How do I deal with this level of uncertainty?”  “I don’t understand how I can schedule the expected delivery date for this project?”  he asked me when I served as a PMO who carried out planning, controls and monitoring of a project work plan.

Jonathan, like many other project managers who have had their “cheese moved,” had to adapt to a development methodology new to him after the company he was working on moved from a development method based on Waterfall methodology to Agile development.

Let’s review the methodologies, their advantages, their disadvantages, and the differences between them:

Waterfall Methodology

A “traditional” development methodology first defined in Winston Royce’s 1970 paper, in which the main phases of the project are scheduled one by one, each step in turn.  According to this method, a stage is never begun before the previous stage ends, i.e., work is carried out in a serial manner.

In a software development project, for example, the following processes will be performed in a sequential manner:

According to the methodology, the transmission testing will not begin before the development phase is completed.

The graphic representation of the description of the development process above illustrates the name of the methodology – “The Waterfall”.

The use of this methodology is done in relatively small projects with a reasonable level of complexity, with products that are documented and clear from the beginning of the project, and when the technology is familiar and perfected.

In the Waterfall methodology, a validity factor is assigned to the critical path of the project.

The critical path is the set of activities in the project in which a delay in one of them will delay the project’s end date (in other words, they lack flexibility). Determination of the critical path is the result of a mathematical calculation performed in project management systems, based on the dependencies between the activities and the constraints that have been determined.

A project manager must manage the activities of the critical path with great attention while verifying their performance according to the design.

In addition, it must be analyzed on a regular basis and should also relate to “near-critical” activities with little flexibility, which may themselves become critical if they are delayed or completely exhaust their flexibility.

In conclusion:

Agile Development Approach

A software development approach that advocates variable planning according to ongoing prioritization and high flexibility in accepting changes and updates in requirements.  Also at its core:

  • A development process that develops over time (from a minimum viable product – MVP – to full software), while conducting demos for interested parties and receiving feedback on an ongoing basis
  • Continuous improvement (an important principle emphasized in Lean methodology)

This approach, with its 4 values and 12 derived principles, was first defined in 2001 by leading software developers in a document called the Agile Software Manifesto, which was based on several software development methodologies, including some of the leaders such as Scrum and Kanban.


The method is based on a number of tools and techniques:

  1. Work in integrative teams:

Work teams are made up of coders, developers, and testers. For example, testers, who in Waterfall technology would wait their turn until after the development stage, are already involved in the early stages of the project, familiarizing themselves with the developed product, writing test plans and automation before testing (Test Driven Development).

This has several notable advantages:

  • In work according to Waterfall, testers often absorb delays of the development team, since the date of delivery to the customer remains fixed. This directly affects the quality of the tests and the burnout of testers.
  • A bug discovered in a Waterfall-run project returns to the developer, who dealt with it several months previously. The need to recall the details of that specific development leads to a waste of time.
  1. “Breaking down” the requirements for User Stories:

Breaking down the requirements for features and user stories, where each story can be independently developed and tested.

It is possible to evaluate the weight of each story in human time and to report through storypoints – which helps to calculate and evaluate the progress of the project’s life (Burn Down).

The collection of stories is stored in the Backlog and is constantly updated, in accordance with the scheduled dates of their implementation.

  1. Striving for the MVP (Minimal Viable Product)

For which constructive feedback can be obtained and can be further developed and improved accordingly.

  1. Iterative Work:
    • In Kanban methodology – managing the flow of current progress so that the transfer rate of a user story from the Backlog to its completion will  take a fixed number of weeks (2-4).
    • In Scrum methodology – working in fixed intervals called sprints with clear goals that also last for a fixed number of weeks (usually 2).

In conclusion:

He now understood that the “crisis” he faced was in fact an opportunity.

An opportunity to assimilate a work method that enables us to cope with the frequent changes that are an integral part of software development in particular, and project management and life in general.

Besides changing the method of development, the company has adopted Lean practices such as Retrospective Meetings, one of whose principles is “continuous improvement”. Once every few weeks, a project team meets to study and apply lessons learned, because why wait for the completion of a project if certain points can be improved during operation?

Today, a growing number of companies are adopting the Agile approach, which enables them to maintain flexibility and give attention to their customers with shorter response times, to present demos to customers with minimal viable products in the early stages, and to receive feedback about features and development activities in real time..

By: Shay Zuker PMP®