Agile or fragile? Why waterfall is simply the better choice for some projects
Agile project management is now considered standard practice in many companies – almost a matter of faith. “Agile” sounds modern, while “waterfall” sounds like a 90s specification document. At the same time, decision-makers often experience the opposite of the promised effects in practice: budgets explode, deadlines are still missed, and the ROI remains vague.
This podcast episode clears up typical misconceptions: Agility is neither haphazard nor documentation-free – and above all, it is not automatically the best choice.
The context is crucial: requirements, regulations, dependencies, team setup, decision-making culture. The goal is to choose a method that is based on business needs – not on trend pressure.
Key Points
- “Agile does not mean that you don't make a plan.”
- “True agility requires sharply defined roles and very precise prioritization.”
- “If everyone says, ‘We have to implement everything anyway,’ then in principle it's no longer an agile project.”
- “The moment I have external dependencies, I'm actually no longer really agile.”
- “The big advantage of agile projects is that I can leave things out – not that I can throw anything in.”
- “Hybrid only works if it is deliberately designed – otherwise you get the worst of both worlds.”
Summary
1) Agile is often misunderstood – and then it becomes expensive.
Agile does not mean “starting without requirements” or “everything will become clear later.” Without clear roles, hard prioritization, real decision-making ability, and continuous coordination, there is no agility, only chaos – with unpredictable costs and schedules.
2) A real product owner is not optional.
Agile projects need someone who is really allowed to make product decisions. If every decision has to go through committees, agility loses its core advantage: fast, clear prioritization along a product vision.
3) Agility often fails because of dependencies – not because of the method.
Legal, security, specialist departments, platform teams, external APIs, hardware, authorities: as soon as critical suppliers are not integrated into the team, sprint planning becomes an illusion. A cross-functional team is therefore a key prerequisite.
4) Waterfall (or other linear approaches) make sense when stability, regulations, and fixed prices are involved.
If requirements are stable and known (e.g., internal integration projects), if strict regulatory audit trails dominate (medicine, automotive, aviation), or if a true fixed price with fixed scope is required, a classic approach may be more suitable – because it provides clarity, verifiability, and interface planning early on.
5) Cost issue: Agile is not automatically cheaper – but often less risky in reality.
Agile has overhead and tends to be more expensive for an identical, fully known scope. The practical advantage arises because you learn earlier, correct earlier, and, above all, can consciously reduce (control scope) instead of realizing late in the project that assumptions were wrong.
6) Hybrid can work – if you separate the core and flex zones.
A practical model:
- Design the core product cleanly and, if necessary, specify it in the traditional way (for testing, clear communication, deliveries).
- Extensions/optimization should then be developed further in an agile manner (market feedback, version 2.0, iterations).
Hybrid becomes powerful when it is not “half agile, half waterfall,” but is consciously designed along the lines of project reality.
Not “agile at any price,” but method selection based on business context: requirements, dependencies, regulations, team capabilities, decision-making culture. Agility is powerful—but only if the organization can truly create the conditions for it.
