Agile vs. waterfall method - comparison and differences
In the current working world, people constantly hear that we are in the VUCA world, and that we have to adapt to our ever-changing environment. Everyone is talking about being in a transformation towards agility. Some people may not be able to see through, and still wonder what this means for organizations.
In contrast to what’s called the waterfall methodology, agility is in a completely different ball park. Trying to understand what waterfall vs. agile methodology is and which is more suitable when, can be quite confusing.
If you also feel confused, this article may be of great help. Here we explain clearly the differences and similarities between waterfall and agile.
The waterfall model
In line with the proverb “new brooms sweep clean, but old brooms know every corner”, the tried and tested waterfall methodology is used in many companies. This is not surprising and certainly not always wrong, because the waterfall model is one of the classics of project management, and has proven effective in many cases.
But what does Agile vs. Waterfall actually mean in concrete terms? The waterfall model is a linear process model in which the process is organized into successive project phases with specifically defined start and end points. Roughly, you can imagine it like this:
Before we go any deeper, a quick note. We recently had 11 international senior agile practitioners as guests in one of our webinars, asking one question: How do you scale agile methods the right way?
The result of this is the following fantastic video recording that answers some of the key questions when scaling agile, for example:
- Should you start your agile transformation rather bottom-up or top-down?
- How do you align leadership on a common goal and vision?
- How do you choose the right agile framework – and why is that actually not that important?
My recommendation: take a look! The video is rather long, but every single minute is worth it.
Let’s examine this with 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.
As a wise man once said: “If it ain’t broke, don’t fix it.”
Agile (iterative) vs. Waterfall (linear) methodology
Even when the waterfall model has good aspects and is effective in many situations, companies should get involved in becoming more agile. Why? Because the world in which we all operate, places ever more complex and contradictory demands on us, and with waterfall thinking, we often find it difficult to react to these situations.
The waterfall method involves some dangers. Although we have a high sense of security due to the planning and structure, we are also bound and limited in our cycle of work. The work process is rather static, and due to exact planning we have very little flexibility: which is 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 methodologies.
But what is the definition of agile? According to Duden , agile is something along the lines of “evidence of mobility; active and flexible” 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 actual, current circumstances. This is essential, because we are confronted with complex changes due to digitization and demographic change and therefore have to remain adaptable.
By the way, a quick note in the context of agile transformation: Do you want to make sure that you are currently setting the right priorities in your agile transformation?
Then take our maturity check for your agile transformation - only takes 3 minutes. You even get a benchmark based on over three hundred other participants. See button 🙂
Building 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 like the sketch 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 to their satisfaction.
Perhaps the customer will then say: “Oh no, I think I would prefer pine wood instead of cherry wood.” After all this, a different type of wood has to be chosen. 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 a more 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 during. This would have significantly higher correction costs than a flexible adjustment.
"Many team members are afraid to speak up!"
Solve this challenge
"We discover too many unexpected issues & bugs at a late stage!"
Solve this challenge
"Why does it sometimes take me hours to prepare a simple retrospective?"
Solve this challengeAgile vs. Waterfall methodologies 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 a professional context, have been socialized for decades with a waterfall-style mindset.
Risk aversion here refers to the tendency, in decision-making situations, to choose the option that involves the least risk - i.e. the least loss - with regard to the outcome. (cf. Kahneman & Tversky, 1979)
Agile vs. Waterfall methods require us to give up this supposed security: Instead of resorting to tried and tested methods and using fixed structures and principles, old patterns of the planning fallacy are broken up and iterative methods are used. This initially leads to a perceived increase in uncertainty, as one has to apply new - apparently risky - approaches that interpret uncertainty as part of the plan.
Scheduling this uncertainty leads to a necessary flexibility in the long term. We develop a range of options for action, which conversely stabilizes security in a VUCA working world.
Keep dynamics and stability in balance
The agile methodology - like the waterfall methodology - involves certain disadvantages:
- Agile methods make planning uncertainties visible and take them into account, so that plans must include space for new insights
- A concrete result is more difficult to estimate, since new knowledge can make it possible to deviate from the originally 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 type of project in question.
The waterfall model is especially suitable for projects that are already well-known and include fixed requirements in advance .
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.
By the way: If you want to specifically promote the agile mindset in your team or company, it is worth taking a look at our article on amazing truth behind the agile mindset .
Agile or Waterfall methodology or a combination of both?
With all the hype surrounding “agile”, one can sometimes tend to see agile methods as a panacea. Wrongly so. The perhaps surprising result of this text is clear.
It turns out that the use of both methodologies combined leads more efficiently to the goal (Herrmann, 2007). Such combinations make sense in situations where the waterfall model is called for, but is not adequate to the complexity of the project.
A kind of middle ground of both methods is called Feature driven development (FDD).
With the FDD, one develops - as with the waterfall method - a concrete, long-term plan with individual, fixed sequences: the features. However, the individual features are very short, which allows short-term reactions to changing requirements. Although the approach is not as iterative as agile methods, it may represent an appropriate compromise.
And so we come to the rather astonishing result: It doesn’t always have to be Agile vs. Waterfall method. The two methods can certainly complement each other. Both have their justification. Depending on the project and context.
But since agile methodologies are still uncharted territory for many, it’s still alright to ask: How does one try out new agile methods?
Not sure where to start?
For many, “agility” is still new territory. They rightly ask themselves the question: Should I rather do the project agile or according to waterfall? How would I even start with agile methods? An “agile” answer to this would be: Start experiments. Iteratively try out different things.
Agile methods are traditionally introduced in two ways, which are also excellent for “beginners”: Kanban and retrospectives.
Kanban and retrospectives as a conventional starting point
Kanban uses a publicly visible (Kanban) board, on which every team member makes their current activities visible to the rest of the team. This promotes communication, efficiency and ultimately, project success. You can find more information about Kanban right here.
In retrospectives, the basic idea is to actively reflect as a team on a regular basis. Typically every two weeks, you meet in a retrospective meeting and ask, for example, the questions: What is going well? What not so good? And what measures can we take to make things run better?
If you are thinking about introducing agile methods…
By the way, if you are still looking for a suitable retro board, our article can help you with the topic: Comparing the 6 best retrospective boards
References
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.
