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 waterfall vs. agile even mean in practice? 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. Roughly sketched out, it looks something 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, someone must determine what is going to be developed or created. For example: the customer wants a table. You then analyze and define the requirements, creating a plan of what has to be done. A draft or product design is then drawn up, in our example this would probably be a sketch of the table.
In the implementation phase, the whole thing becomes more tangible: we select materials, determine the exact dimensions and build the table. During inspection, we check if everything works the way we planned for it to: is the table standing? Are the proportions correct? The evaluation is then carried out with the customer. We deliver 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, talking about agile transformation... one quick hint: Do you want to make sure that you are setting the right priorities in your agile transformation ?
Fill out our agile maturity assessment for your agile transformation – it only takes 3 minutes! You will even get a benchmark based on the more than 300 participants we already have. Have fun 🙂
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.
Most Agile Coaches and Scrum Masters run in circles...
...fixing superficial symptoms. Time to use psychology to foster sustainable mindset change.
Agile 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 denotes the tendency to choose the option in decision-making situations with the least risk - one with the least possible losses - in terms of the outcome. (see Kahneman & Tversky, 1979)
The agile vs. waterfall methodology 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 - and seemingly risky - approaches must be used, 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 as well as the waterfall methodology includes 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 methodologies are particularly ideal for projects in which many unpredictable factors can occur, and therefore require flexible reflection loops. In most technological projects, such uncertainty is inevitable, which is why agile methods are on the rise.
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 around "agile", you may tend to see agile methods as a cure-all. That is not the right way to think. Our conclusion for this text should be quite clear by now :)
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 - much like the waterfall methodology - a concrete, long-term plan with individual, pre-defined sequences: known as the features. However, the individual features are very short, which means that short-term reactions to changing demands are possible. The procedure is not as iterative as agile methodologies, but it may represent an appropriate middle ground.
And so we come to the rather astonishing result: It doesn't always have to be agile vs. the waterfall methodology. The two methodologies can also complement each other. They are equally justified, 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 uncharted territory. It's always correct to ask: Do I prefer to make the project lean towards agile or waterfall? How would I start with an agile methodology? An “agile” answer to this would be: start experimenting. Try different things iteratively.
Typically, agile methods are introduced in two ways, which are also ideal 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.
https://www.pinuts.de/blog/webstrategie/projektmanagement-wasserfall-gegen-scrum
