Die Entscheidung zwischen Agile und Waterfall bestimmt das Kostenmodell, das Risikoprofil und den Reporting-Rhythmus eines Softwareprojekts, noch bevor die erste Zeile Code geschrieben wird. Jeder hat dazu eine Meinung. Und meistens bedeutet die Bevorzugung der einen Methode, die andere komplett abzuschreiben.
Stellen Sie es sich wie einen Kanal im Vergleich zu einem Fluss vor. Ein Kanal wird vermessen, kalkuliert und einmal ausgehoben; er leitet das Wasser genau dorthin, wo es fließen soll. Ein Fluss sucht sich sein eigenes Bett und kommt auch ans Ziel, nur eben nicht auf dem Weg, den man vorgezeichnet hat. Keine der beiden Methoden ist grundsätzlich besser, um Wasser zu bewegen. Es kommt auf den Untergrund an.
Die kurze Antwort: Nutzen Sie das Wasserfallmodell wenn die Anforderungen stabil sind, sich das externe Umfeld voraussichtlich nicht ändert und ein fester Projektumfang sowie ein festes Budget wichtiger sind als Anpassungsfähigkeit. Nutzen Sie den agilen Ansatz wenn sich die Produktvision ändern kann, wenn Sie frühzeitig funktionierende Software benötigen oder wenn die Kosten dafür, sechs Monate lang das Falsche zu entwickeln, höher sind als die Kosten für eine zweiwöchentliche Neuplanung.
Ist Waterfall tot? Hat Agile es abgelöst? Ist eine Methode besser als die andere? Dieser Artikel beleuchtet den aktuellen Stand beider Methoden, beantwortet die Fragen, die in Scoping-Gesprächen tatsächlich aufkommen, und erklärt, warum wir bei Imaginary Cloud uns für Agile statt Waterfall entschieden haben – und in welchen Fällen wir es dennoch nicht tun würden.
Die Wasserfall-Methodik verdankt ihren Namen den aufeinanderfolgenden Phasen, die wie bei einem echten Wasserfall stufenweise angeordnet sind, wobei jede Phase einen Schritt zwischen dem Anfang und dem Ende darstellt. Winston Walker Royce beschrieb sie 1970 in seinem Beitrag Managing the Development of Large Software Systems für die IEEE WESCON-Konferenzberichte. Ursprünglich sah sie fünf verschiedene Phasen vor: Anforderungen, Entwurf, Implementierung, Verifizierung und Wartung.
Hier ist der Teil, den Vergleichsartikel meist auslassen. Royce stellte das rein sequentielle Modell als eine Version dar, die „riskant ist und zum Scheitern einlädt“, und verbrachte den Rest des Beitrags damit, für Iterationen zwischen den Phasen zu plädieren. Was die meisten Leute als Wasserfall bezeichnen, ist das Diagramm. Nicht die Argumentation dahinter.
In den folgenden Jahrzehnten entstanden zwar Variationen, doch die Logik blieb bestehen. Sobald eine Phase abgeschlossen ist, wird deren Ergebnis zum Input für die nächste, die unmittelbar darauf folgt. Ihre Einfachheit machte sie leicht verständlich und leicht anwendbar. Wasserfall stellt sicher, dass jede Phase beendet ist, bevor die nächste beginnt – um zu verhindern, dass die Entwicklung startet, bevor die Entwurfsarbeit abgeschlossen ist, was sonst zu Inkonsistenzen an beiden Enden führen würde. Das Modell beruht zudem auf der Annahme, dass man die Kosten und den Aufwand des gesamten Projekts bereits in der Anforderungsphase abschätzen kann. Das gilt allerdings nur so lange, wie die Anforderungen selbst Bestand haben.
Das Wasserfallmodell war nie der einzige mögliche Ansatz. Doch es dauerte bis 2001, bis es mit einem grundlegenden Paradigmenwechsel konfrontiert wurde. Was war der Grund? Agile.
Die Prinzipien der inkrementellen Entwicklung wurden bereits angewandt, wenn auch verstreut über verschiedene Prozesse. Erst im Jahr 2001, mit dem Manifest für Agile Softwareentwicklung, wurde Agile, wie wir es heute kennen, eingeführt und populär gemacht. Ein sehr direktes Dokument, das von einer Gruppe von Entwicklern in Snowbird, Utah, zusammengestellt wurde und die Konventionen der Softwareentwicklung auf einen Schlag brach. Plötzlich gab es eine echte Alternative zum Wasserfallmodell.
Die Zyklen von Agile, üblicherweise Sprints genannt, liefern kumulativ einen Mehrwert; jeder einzelne ist Teil eines größeren Ganzen, das zur Fertigstellung führt. Genau hier unterscheidet es sich am stärksten vom Wasserfallmodell. Der Ansatz strebt nach Flexibilität. Er ermöglicht regelmäßige Inkremente und verkürzt die Planungszeit durch die Arbeit in kürzeren Zeitfenstern: feste Zeiträume von ein oder zwei Wochen, in die die Arbeit eingepasst wird, anstatt umgekehrt. Jede Iteration liefert zum Abschluss funktionierende Software und plant den nächsten Schritt detaillierter als die weiter in der Zukunft liegenden.
Der Mechanismus, der dies ermöglicht, ist das Backlog: eine geordnete Liste mit allem, was das Produkt benötigen könnte, aus der jeder Sprint die jeweils wertvollsten Elemente zieht. Änderungen werden durch eine Neuordnung dieser Liste gehandhabt, nicht durch das erneute Aufrollen eines Plans.
Zahlreiche Teilbereiche übernehmen Agile als Philosophie, ähnlich wie sich um das Wasserfallmodell herum verschiedene Varianten entwickelten. DSDM, Feature-Driven Development, Extreme Programming und das wahrscheinlich populärste, Scrum, nutzen alle Agile für die Softwareentwicklung. Ehrlich gesagt ist das Label weit weniger wichtig als die Frage, ob das Backlog tatsächlich neu priorisiert wird – der Teil, den die meisten Anwender stillschweigend überspringen.
Fast genauso viele Menschen behaupten, Wasserfall sei tot, wie diejenigen, die Agile für einen unbedeutenden Trend halten. Unterschiedliche Meinungen sind völlig in Ordnung. Schauen wir uns die Fakten an – und diese haben sich seit den Umfragen, die in den meisten Artikeln noch immer zitiert werden, weiterentwickelt.
Jahrelang war die Stack Overflow Developer Survey von 2018 die Standardreferenz, die Agile bei etwa 85 % und Wasserfall bei rund 15 % sah. Diese Zahl ist veraltet, und zwar nicht, weil Wasserfall zusammengebrochen ist, sondern weil sich die Fragestellung geändert hat. Spätere Umfragen hörten ganz damit auf, eine klare Trennung der Frameworks abzubilden: Die neueren Entwicklerumfragen von Stack Overflow verlagerten ihren Fokus auf Tools und die Einführung von KI, und der State of Agile -Bericht (das meistzitierte Barometer der Branche) strich in seiner Ausgabe 2025 nach siebzehn Jahren die Frage „Welches Framework verwenden Sie?“ komplett.
An die Stelle des Zweikampfs ist eine klare dritte Antwort getreten: Hybrid. Laut dem 18th State of Agile Report (Digital.ai, 2025)nutzen mittlerweile etwa 74 % der Unternehmen hybride oder selbst entwickelte Ansätze anstelle eines einzelnen reinen Frameworks – ein Anstieg von etwa 10 % vor einem Jahrzehnt. Derselbe Bericht ergab, dass nur etwa 13 % angeben, Agile sei tief im Unternehmen verankert ; die meisten beschreiben es als vorhanden, aber nicht vollständig funktionierend. Unterdessen berichtet das Project Management Institute in seinem Pulse of the Profession seit Jahren, dass mehr als die Hälfte der Unternehmen in ihrem Portfolio nach wie vor traditionelle, strukturierte Methoden einsetzt.
Bei genauer Betrachtung zeigt sich: Die Geschichte ist nicht, dass Wasserfall gestorben ist und Agile gewonnen hat. Die Geschichte ist, dass reine Ansätze verloren haben und der Mittelweg dominiert. Daraus ergeben sich zwei Schlussfolgerungen:
Agile Methoden haben zweifellos echte Schwächen des Wasserfallmodells aufgezeigt: wie schwierig es ist, Fehler zu beheben, die in früheren Phasen entdeckt wurden, und dass man den gesamten Prozess durchlaufen muss, bevor man funktionierende Software in den Händen hält, wobei dazwischen große Unsicherheit herrscht. Doch sich für das eine oder das andere zu entscheiden, nur um besser dazustehen, ist eine Illusion. Meist kaschiert dies lediglich das Fehlen eines echten Prozesses.
| Dimension | Wasserfall-Modell | Agiler Ansatz |
|---|---|---|
| Anforderungen | Festgelegt und freigegeben, bevor das Design beginnt | Entwicklung wird erwartet; Verfeinerung in jeder Iteration |
| Kostenmodell | Schätzung für das gesamte Projekt im Voraus erstellt | Schätzung pro Iteration anhand eines laufenden Budgets |
| Risikoprofil | Konzentriert sich auf das Ende, bei Integration und Tests | Über Sprints verteilt und frühzeitig erkannt |
| Dokumentation | Umfangreich, Phase für Phase erstellt | Schlanker, wird nur dort erstellt, wo sie einen Mehrwert bietet |
| Einbindung der Stakeholder | Konzentriert auf Anforderungen und Abnahme | Kontinuierlich, mit einem Review in jedem Sprint |
| Lieferrhythmus | Eine einzelne Veröffentlichung am Ende | Lauffähige Software am Ende jedes Sprints |
| Umgang mit Änderungen | Formeller Änderungsantrag, meist neu verhandelt | Neu priorisiert im Backlog bei der nächsten Planungssitzung |
| Optimal geeignete Projekte | Stabiler Umfang und stabiles Umfeld, hohe Compliance-Anforderungen | Unsicherer Umfang, sich verändernde Märkte, neue Produkte |
Der Wasserfall-Ansatz ist die bessere Wahl für stabile Projekte. Die intensive Planung findet zu Beginn statt und berücksichtigt jeden Aspekt (intern wie extern), der die Umsetzung beeinflussen könnte. Unabhängig von der Projektgröße eignet sich Wasserfall für Umgebungen, in denen sich während der Entwicklung voraussichtlich nichts ändert. Für diese Art von Arbeit war Wasserfall schon vor der Einführung von Agile der bessere Ansatz – und das ist er immer noch. Wenn Sie das gesamte Projekt in einem risikoarmen Umfeld im Voraus planen können, bringt Ihnen die Aufteilung in Sprints keinen Mehrwert. Konzentrieren Sie sich stattdessen auf das Endergebnis.
Agile ist der richtige Weg für Projekte mit einer flexibleren, unvorhersehbaren Natur. Wenn sich die Produktvision aufgrund der Marktdynamik ändern kann, sollten Sie mit Agile entwickeln und anpassen. Es ist zudem die bessere Methode, um sicherzustellen, dass ein Projekt nicht monatelang in der Entwicklung verschwindet, ohne Ergebnisse zu zeigen. Jeder Sprint endet mit einem Checkpoint, an dem der Product Owner die abgeschlossene Arbeit testen und abnehmen kann. Und ein MVP fügt sich ganz natürlich in diesen Rhythmus ein.
Bei veränderungsanfälligen Projekten, die nach dem Wasserfall-Modell durchgeführt werden, bergen die fehlenden Checkpoints Risiken, da Probleme, die erst am Ende entdeckt werden, schwerer zu beheben sind. Die zusätzliche Zeit, die in die Planung des gesamten Projekts investiert wird, garantiert nicht, dass Design und Entwicklung reibungslos bis zum Abschluss verlaufen. Die meisten Probleme sind ebenso unerwünscht wie unvorhersehbar.
Bevor eine Methodik festgelegt wird, entscheiden vier Faktoren über den Erfolg. Ordnen Sie Ihr Projekt in den untenstehenden Zeilen ein: Je weiter es links liegt, desto eher ist Wasserfall geeignet; je weiter rechts, desto eher Agile. Eine klare Aufteilung ist kein Zeichen für Unentschlossenheit, sondern das Argument für einen bewussten hybriden Ansatz.
Die Entscheidung zwischen Agile und Waterfall ist mehr als nur eine Marketingstrategie. Wer das falsche Werkzeug wählt, zahlt mit Zeit und Aufwand drauf. Für alle, die das Budget freigeben, sind vier Konsequenzen entscheidend.
Budgetvorhersehbarkeit. Waterfall liefert früh eine feste Zahl – genau das, was ein Vorstandspapier verlangt. Diese Zahl ist jedoch nur so präzise wie die Anforderungen, auf denen sie basiert: Die Vorhersehbarkeit ist real, wenn der Projektumfang tatsächlich fix ist, und illusorisch, wenn er es nicht ist. Agile bietet stattdessen eine kontrollierte Burn-Rate: weniger Gewissheit über die Gesamtsumme, aber mehr Sicherheit darüber, was man für jeden investierten Monat erhält.
Umgang mit Änderungen. Bei Waterfall ist jede Änderung nach der Freigabe ein Change Request, der hinsichtlich Preis und Termin neu verhandelt werden muss. Bei den Festpreisprojekten, die wir durchgeführt oder übernommen haben, sind genau diese Nachverhandlungen der Punkt, an dem Marge und Zeitplan meist auf der Strecke bleiben. Bei Agile werden Änderungen durch eine Neupriorisierung des Backlogs aufgefangen; die Kosten entsprechen dabei dem Wert dessen, was dafür weichen muss.
Time-to-First-Value. Waterfall liefert den Mehrwert erst ganz am Ende. Agile liefert in jedem Sprint etwas Nutzbares – ein entscheidender Vorteil, wenn das Produkt bereits vor der vollständigen Fertigstellung Nutzern, Regulierungsbehörden oder Investoren präsentiert werden muss. Deshalb lässt sich ein MVP ganz natürlich in einen agilen Prozess integrieren, während es bei Waterfall oft zu Reibungsverlusten führt.
Governance und Reporting. Waterfall berichtet den Fortschritt anhand eines Plans, was sich vor einem Lenkungsausschuss gut liest, aber Integrationsrisiken bis spät in den Prozess verbergen kann. Agile berichtet anhand funktionierender Software, die sich schwerer beschönigen lässt, und erfordert Stakeholder, die sich alle zwei Wochen statt nur vierteljährlich einbringen können.
Nur wenige der von uns betreuten Unternehmen nutzen eines der beiden Modelle in seiner reinen Form. Wie die obigen Daten zeigen, bilden sie damit mittlerweile die Mehrheit und nicht mehr die Ausnahme. Das am häufigsten beobachtete Muster ist eine phasenbasierte Struktur auf Programmebene mit festen Meilensteinen, Budgets und Compliance-Gates, kombiniert mit agiler Umsetzung innerhalb der jeweiligen Phasen. Discovery und Architektur werden vorab geplant, während die Entwicklung anschließend in Sprints innerhalb dieses Rahmens erfolgt.
Es funktioniert, wenn die Grenze bewusst gezogen wird. Es scheitert, wenn sie zufällig entsteht: ein fester Umfang, ein fester Termin und ein festes Budget, bei denen Sprints nur aufgesetzt werden, ohne dass Spielraum für Anpassungen besteht. Sprints allein schaffen keine Flexibilität. Die Fähigkeit, Prioritäten zu ändern, tut dies.
Ein konkreter Fall macht die Abwägungen weniger abstrakt. FlippedNormals, ein Marktplatz für digitale Kunst und 3D-Assets, kam mit einer Plattform auf uns zu, die ihren ursprünglichen Anforderungen entwachsen war: Sie basierte auf WordPress, und die Technologie selbst war zu einer Wachstumsbremse geworden. Die Aufgabe bestand darin, den Marktplatz von WordPress auf eine maßgeschneiderte Plattform zu migrieren und für eine besser skalierbare Infrastruktur auf AWS umzuziehen – und Zeit war dabei kein Luxus, da der bestehende Stack das Geschäft aktiv einschränkte.
Genau das ist die Art von Projekt, bei der sich die Wahl der Methodik bezahlt macht. Ein Neuaufbau mit Migration bei einem laufenden Marktplatz ist keine feste, vorhersehbare Spezifikation, die man einmal kalkuliert und dann abarbeitet; es ist ein bewegliches Ziel, bei dem sich die Kosten einer Fehlentscheidung mit jeder Woche, die die alte Plattform weiterläuft, summieren. Deshalb haben wir das Projekt in Schritten umgesetzt, die neue Plattform in Teilbereichen aufgebaut und das Unternehmen an jedem Kontrollpunkt auf dem Laufenden gehalten, anstatt für ein Quartal abzutauchen und auf das Beste zu hoffen.
Das Grundprinzip gilt unabhängig von der genauen Zahl: Wenn die Technologie der limitierende Faktor ist und der Zeitdruck real, ermöglicht eine schrittweise Bereitstellung, Risiken nach und nach zu eliminieren, anstatt den Erfolg auf eine einzige riskante Komplettumstellung zu setzen.
Warum bevorzugen wir also Agile gegenüber dem Wasserfallmodell? Sprüche wie „Der Wasserfall ist tot, lang lebe Agile“ lassen wir mal außen vor. Grundsätzlich ist das eine nicht besser als das andere, und meistens ist es ein Fehler, das anders zu sehen. Wir haben lange Zeit nach dem Wasserfallmodell gearbeitet und sind zu Agile gewechselt, als wir feststellten, dass es aufgrund der Art unserer Projekte einfach besser zu uns passt.
In unserem Entwicklungsprozess setzen wir auf Scrum, eine Teilmenge von Agile, die wir für die Bedürfnisse unserer Kunden angepasst haben. Zuerst steht die Discovery-Phase, gefolgt von einem Proof of Concept, der in einem MVP münden kann, und anschließend eine Reihe von Sprints, die schrittweise Mehrwert schaffen. Jeder Sprint endet mit einer Definition of Done, die wir mit dem Kunden vereinbaren, damit „fertig“ für beide Seiten dasselbe bedeutet.
Bei unseren Projekten handelt es sich meist um neue digitale Produkte, bei denen sich die Anforderungen mit zunehmendem Wissen ändern – genau das Szenario, für das Agile entwickelt wurde. Würden wir ein Projekt mit festem Umfang und einer regulatorischen Deadline umsetzen, sähe die Rechnung anders aus – und das würden wir auch so kommunizieren. Es wäre ein Fehler, diesen Prozess als die bestmögliche Lösung für jedes Projekt zu betrachten; deshalb überprüfen und passen wir ihn bei Bedarf an. Universallösungen gibt es bei uns nicht.
Ja, und die meisten Unternehmen tun dies heute. Der gängige Hybrid-Ansatz behält auf Programmebene eine phasenbasierte Struktur mit festen Meilensteinen und Compliance-Gates bei, während die Umsetzung innerhalb der Phasen agil erfolgt. Dies funktioniert, wenn die Grenze zwischen dem Starren und dem Flexiblen bewusst gezogen wird; es scheitert jedoch, wenn Umfang, Termin und Budget gleichzeitig fixiert werden.
Keines von beiden ist von Natur aus günstiger. Waterfall bietet eine einmalige Kostenschätzung zu Beginn, was kosteneffizient ist, solange die Anforderungen stabil bleiben, aber teuer wird, wenn sich Änderungswünsche häufen. Agile arbeitet mit einem laufenden Budget und senkt das Risiko, das Falsche zu entwickeln, allerdings ist die Gesamtsumme zu Beginn weniger vorhersehbar.
Waterfall lässt sich natürlicher auf einen Festpreis für einen festen Umfang anwenden, da beide Parteien vor Arbeitsbeginn vereinbaren, was geliefert werden soll. Agile kann ebenfalls als Festpreisvertrag gestaltet werden, indem Budget und Zeitrahmen statt des Umfangs begrenzt werden, wobei das Backlog innerhalb dieses Rahmens priorisiert wird.
Ja. Es ist nach wie vor in regulierten Branchen, bei öffentlichen Ausschreibungen und bei Integrationsprojekten mit festen externen Abhängigkeiten verbreitet, bei denen Dokumentation, Phasenfreigaben und ein definierter Umfang vertragliche Anforderungen und keine bloßen Präferenzen sind.
Waterfall oder ein hybrider Ansatz sind dort üblicher, wo Auditoren Nachweise für Phasenfreigaben erwarten. Agile kann dieselben Anforderungen erfüllen, jedoch müssen Dokumentation und Rückverfolgbarkeit bereits in der Definition of Done eingeplant werden, anstatt sie als gegeben vorauszusetzen.
Beginnen Sie mit der Stabilität der Anforderungen. Wenn der Umfang jetzt spezifiziert werden kann und Bestand hat, ist Waterfall praktikabel. Wenn es kostspielig wäre, eine falsche Annahme erst spät zu entdecken, wählen Sie Agile. Prüfen Sie anschließend die Vertragsgestaltung, die Verfügbarkeit der Stakeholder und die erforderlichen Compliance-Nachweise – das sind die vier oben genannten Kriterien.
Bei Waterfall wird jede Phase abgeschlossen, bevor die nächste beginnt, und das Ergebnis wird erst am Ende geliefert. Agile arbeitet in kurzen Iterationen, die jeweils funktionierende Software liefern, sodass die Anforderungen verfeinert werden können, während das Produkt Gestalt annimmt.
Waterfall ist nicht tot, und Agile ist nicht per se die bessere Wahl. Beide als Standard zu betrachten, ist der gefährlichere Weg in der Softwareentwicklung. In den letzten Jahren wurde „Agile zu sein“ zu einem Statussymbol für Unternehmen – und dieser ganze Trubel macht es schwerer zu erkennen, wofür Waterfall und Agile eigentlich gedacht sind.
Verschaffen Sie sich also einen Überblick, bevor Sie sich für den Kanal oder den Fluss entscheiden. Anforderungsstabilität, Änderungskosten, Vertragsmodell und Compliance-Nachweise sind die vier entscheidenden Kriterien. Verstehen Sie die Bedürfnisse Ihres Projekts, wählen Sie die passende Methode und passen Sie diese im Verlauf an.
Sie denken über das Bereitstellungsmodell für Ihr nächstes Projekt nach? Wir besprechen das gerne mit Ihnen – auch in Fällen, in denen Waterfall die richtige Antwort ist. Gesprächstermin buchen und wir gleichen Ihre Anforderungen, Rahmenbedingungen und Ihr Vertragsmodell mit dem passenden Ansatz ab.
Content Manager, Texteditor und Moderator strategischer Ideen. Außerdem ist er ein begeisterter Fan der Filmkunst und des visuellen Geschichtenerzählens.
People who read this post, also found these interesting:
.webp)
