Our blog articles are translated to English by machine and may not always be accurate - sorry for that.

If you understand German, we recommend to switch to the German version.

Wasserfall Modell

Agile vs. Waterfall method & #8211; Comparison and differences

Share on linkedin
Share on twitter
Share on facebook
Share on email

In the world of work, people constantly hear that we are in the VUCA world and that we have to adapt to our constantly changing environment. Everyone is talking about being in a transformation towards agility. Some people may not be able to see through and wonder what that means for organizations. 

In contrast to the so-called waterfall methodology, agility is a completely different caliber. Trying to understand what Agile vs. Waterfall method is and which is more suitable when, you can get confused. 

If you feel the same way, we may be able to remedy the situation below, because here we explain what agile vs. Waterfall means. 

Waterfall model

In line with the motto “Old brooms sweep well”, the tried and tested waterfall method is used in many companies. This is not surprising and certainly not always wrong, because the waterfall model is the classic of project management and has proven in many cases that it can be effective.

But what does agile vs. Waterfall at all concrete? The waterfall model is a linear process model, in which the procedure is organized in successive project phases with specifically defined start and end points. You can roughly imagine it like this:

Wasserfall Modell

Let's look at the whole time using a simple example:

In the definition phase it is first determined what is to be created. For example, the customer specifies a request: he wants a table. You then analyze and define the requirements and create a plan of what has to be done. In the design you then create a product design, in our example a sketch of the table. 

In the implementation phase the whole thing becomes more tangible: we select material, determine the exact dimensions and build the table. In the control we check whether everything works as we planned: is the table standing? Are the proportions correct? The evaluation is then carried out together with the customer: We hand over the product and receive feedback. 

So why change something when you say so nicely: Never change a running system.

Agile (iterative) vs. Waterfall (linear) methodology

Even if the waterfall model definitely has good sides and is effective in many situations, companies should get involved in becoming more agile. How so? Because the world in which we all operate places ever more complex and contradictory demands on us and we often find it difficult to react with waterfall thinking.

The waterfall method involves some dangers. Although we have a high sense of security due to the planning and structure, we are also very bound in our processes. The work process is rather static and due to the exact planning we have very little flexibility. And that's exactly what we need in our dynamic environment. This is where agility comes into play. So let's take a look at Agile vs. Waterfall method.

But what is the definition of agile anyway? According to the Duden is agile something like “evidence of mobility; agile and agile”And this definition can be easily transferred to the world of work. 

Agility in companies means that you are able to iteratively adapt strategies, structures and processes to the actual, current conditions. This is essential because we are confronted with complex changes due to digitization and demographic change and therefore have to remain adaptable. 

Build a table with agile methods

Let's stay with the same example as before: the customer wants a table. So first we start by making a sketch. I show this to the customer and he then decides whether he imagined it or not. If not, the sketch will be adjusted again. As soon as the sketch is finished, I select the material and continue to ask the customer iteratively whether everything is going to their satisfaction.

Perhaps the customer will then say: "Oh no, I think I would prefer pine wood instead of cherry wood." Then the table is assembled and here too the customer is regularly interviewed and changes are made if necessary.
You can see that the agile methodology allows us to react flexibly to changing requirements, which is relevant in the complex environment. 

Therefore the statics of the waterfall methodology are not always sufficient. In addition, it can happen that errors in implementation due to the rigid conception in the waterfall model only become apparent in the evaluation. This would have significantly higher correction costs than a flexible adjustment. 

Agile vs. Waterfall methods in the world of work

It is often still difficult to make the processes in companies agile and iterative. This is because people are fundamentally more risk-averse and, sometimes in their professional context, have been socialized for decades with a waterfall-style mindset. 

Risk aversion here denotes the tendency to choose the option in decision-making situations which is the one with the least risk & #8211; the least loss & #8211; in terms of the outcome. (see Kahneman & Tversky, 1979)

Agile vs. Waterfall methods require us to give up this supposed security: Instead of using tried-and-tested methods and using fixed structures and principles, old thinking patterns of the illusion of planning are broken down and iterative methods are used. Initially, this leads to a perceived increase in uncertainty, as new & #8211; seemingly risky & #8211; Must adopt practices that interpret uncertainty as part of the plan.

Scheduling this uncertainty leads to the necessary flexibility in the long term. We develop a range of options for action, which conversely stabilizes security in the VUCA working world.

Keep dynamics and stability in balance 

The agile methodology & #8211; as well as the waterfall methodology & #8211; includes certain disadvantages:

  • Agile methods make planning uncertainties visible and take them into account, so that the plans must include more freedom for new insights
  • The concrete result is more difficult to estimate, since new knowledge can make it possible to deviate from the original planned result
  • For the reasons mentioned, success seems less predictable in comparison to the classic waterfall project.

Of course, different approaches are more or less suitable depending on the project.
The waterfall model is especially suitable for projects that already well-known and constant requirements in advance include. 

Agile methods are particularly ideal for projects in which many unpredictable factors can occur and therefore flexible reflection loops are necessary. In most technological projects, such an uncertainty is inevitable, which is why agile methods are on the up.

Agile vs. Waterfall method or combination?

It turns out that the use of both methodologies combined leads efficiently to the goal (Herrmann, 2007). Such combinations make sense in situations where the waterfall model is required but this is not appropriate to the complexity of the project.
A kind of middle way of both methods is the so-called Feature driven development (FDD).


At the FDD you develop & #8211; as with the waterfall methodology & #8211; a concrete, long-term plan with individual, defined sequences: the features. However, the individual features are very short, which enables short-term reactions to changing requirements. The procedure is not as iterative as agile methods, but it may represent an appropriate middle ground. So it does not always have to be agile vs. Waterfall method called.

Finally, teams should continuously reflect on themselves and the introduction of agile methods & #8211; that's what agile retrospectives are for.

By the way, if you are wondering how to run good agile retrospectives and make the progress of your agile transformation measurable & #8211; that goes with the Echometer tool.


Richard H. Thaler, Amos Tversky, Daniel Kahneman, Alan Schwartz, The Effect of Myopia and Loss Aversion on Risk Taking: An Experimental Test, The Quarterly Journal of Economics, Volume 112, Issue 2, May 1997, pages 647-661, https://doi.org/10.1162/003355397555226

Herrmann, A. (2007). Feature driven development between waterfall and agility.




To the point

More articles

Want to get started?

Test team retros with Echometer for free & drive agile work in your organization.