“Digitale Wissenbissen": Agil oder fragil? Warum Wasserfall für manche Projekte einfach die bessere Wahl ist
Agiles Projektmanagement gilt in vielen Unternehmen inzwischen als Standard – fast schon als Glaubensfrage. „Agil“ klingt modern, „Wasserfall“ nach 90er-Jahre-Lastenheft. Gleichzeitig erleben Entscheider in der Praxis häufig das Gegenteil der versprochenen Effekte: Budgets explodieren, Deadlines werden trotzdem gerissen, und der ROI bleibt diffus.
Diese Podcast-Folge räumt mit typischen Missverständnissen auf: Agilität ist weder planlos noch dokumentationsfrei – und sie ist vor allem nicht automatisch die beste Wahl. Entscheidend ist der Kontext: Anforderungen, Regulatorik, Abhängigkeiten, Team-Setup, Entscheidungskultur. Ziel ist eine Methodenwahl, die sich am Businessbedarf orientiert – nicht am Trenddruck.
Key Points
- „Agil heißt auf keinen Fall, dass man keinen Plan macht.“
- „Echte Agilität erfordert messerscharf definierte Rollen und eine sehr präzise Priorisierung.“
- „Wenn alle sagen: ‘Wir müssen eh alles umsetzen’, ist es im Prinzip schon kein agiles Projekt mehr.“
- „In dem Moment, wo ich externe Abhängigkeiten habe, bin ich eigentlich schon nicht mehr wirklich agil.“
- „Der große Vorteil von agilen Projekten ist, dass ich Dinge weglassen kann – nicht, dass ich beliebig Dinge reinkippen kann.“
- „Hybrid funktioniert nur, wenn es bewusst designt ist – sonst bekommt man von beidem das Schlechteste.“
Zusammenfassung
1) Agil wird oft falsch verstanden – und dann wird es teuer.
Agil bedeutet nicht „ohne Requirements starten“ oder „später klärt sich alles“. Ohne klare Rollen, harte Priorisierung, echte Entscheidungsfähigkeit und kontinuierliche Abstimmung entsteht keine Agilität, sondern Chaos – mit unvorhersagbaren Kosten und Zeitplänen.
2) Ein echter Product Owner ist nicht optional.
Agile Projekte brauchen jemanden, der wirklich Produktentscheidungen treffen darf. Wenn jede Entscheidung durch Gremien muss, verliert Agilität ihren Kernvorteil: schnelle, klare Priorisierung entlang einer Produktvision.
3) Agilität scheitert oft an Abhängigkeiten – nicht an der Methode.
Recht, Security, Fachabteilungen, Plattform-Teams, externe APIs, Hardware, Behörden: Sobald kritische Zulieferungen nicht im Team integriert sind, wird Sprint-Planbarkeit zur Illusion. Ein cross-funktionales Team ist daher zentrale Voraussetzung.
4) Wasserfall (oder andere lineare Ansätze) sind sinnvoll bei Stabilität, Regulatorik und Fixpreis.
Wenn Anforderungen stabil und bekannt sind (z. B. interne Integrationsprojekte), wenn strikte regulatorische Prüfpfade dominieren (Medizin, Automotive, Luftfahrt) oder wenn ein echter Fixpreis mit Fixed Scope gefordert ist, kann ein klassischer Ansatz besser passen – weil er früh Klarheit, Prüfbarkeit und Schnittstellenplanung liefert.
5) Kostenfrage: Agil ist nicht automatisch billiger – aber oft risikoärmer in der Realität.
Agil hat Overhead und ist bei identischem, vollständig bekanntem Scope tendenziell teurer. Der praktische Vorteil entsteht, weil man früher lernt, früher korrigiert und vor allem bewusst reduzieren kann (Scope steuern), statt spät im Projekt festzustellen, dass Annahmen falsch waren.
6) Hybrid kann funktionieren – wenn man Kern und Flex-Zone trennt.
Ein praxistaugliches Modell:
- Kernprodukt sauber konzipieren und ggf. klassisch spezifizieren (für Prüfungen, klare Kommunikation, Zulieferungen).
- Erweiterungen/Optimierung danach agil weiterentwickeln (Marktfeedback, Version 2.0, Iterationen).
Hybrid wird dann stark, wenn er nicht „halb agil, halb Wasserfall“ ist, sondern bewusst entlang der Projektrealität designt wird.
Nicht „agil um jeden Preis“, sondern Methodenwahl nach Business-Kontext: Anforderungen, Abhängigkeiten, Regulatorik, Team-Fähigkeiten, Entscheidungskultur. Agilität ist mächtig – aber nur, wenn die Organisation die Voraussetzungen dafür wirklich herstellen kann.
