Agil vs. Wasserfall: Wann welches Vorgehen passt

Das Wasserfallmodell hat einen schlechten Ruf, und ausgerechnet sein angeblicher Erfinder hätte dem zugestimmt. Winston Royce beschrieb 1970 in seinem Aufsatz „Managing the Development of Large Software Systems“ den streng sequenziellen Ablauf von Anforderungen über Entwurf und Programmierung bis zum Test. Direkt danach schrieb er, diese Umsetzung sei riskant und lade zum Scheitern ein. Sein Vorschlag: das Ganze mindestens zweimal durchlaufen, mit einem frühen Prototyp.

Gelesen wurde vor allem das erste Diagramm. Der Rest ging unter. Ein halbes Jahrhundert lang.

Die Debatte „agil gegen Wasserfall“ wird deshalb oft mit Karikaturen geführt. Hier geht es um die Frage, die eigentlich zählt: Welches Vorgehen passt zu deinem Projekt?

Was die beiden Ansätze tatsächlich unterscheidet

Der Kern ist nicht das Werkzeug, nicht das tägliche Stand-up und nicht das Kanban-Board. Der Kern ist, wann Entscheidungen fallen.

Im klassischen Vorgehen fallen die meisten Entscheidungen früh. Erst wird spezifiziert, dann entworfen, dann gebaut, dann getestet. Änderungen später sind möglich, aber teuer, weil sie durch alle Phasen zurücklaufen.

Im agilen Vorgehen fallen Entscheidungen spät und oft. Der Scrum Guide 2020 legt Sprints von höchstens einem Monat fest, an deren Ende ein nutzbares Inkrement steht. Das Scrum-Team umfasst typischerweise zehn oder weniger Personen. Nach jedem Sprint kann der Product Owner umsteuern.

Die Zeile „scheinbar hoch“ ist bewusst so formuliert. Ein Wasserfallplan zeigt einen festen Termin. Ob der hält, hängt davon ab, ob die Anforderungen zu Beginn richtig waren. Agile Planung dreht das um: Termin und Budget stehen, der Umfang passt sich an.

Woher das agile Denken kommt

Im Februar 2001 trafen sich 17 Softwareentwickler im Skiort Snowbird in Utah und formulierten das Agile Manifest. Vier Wertepaare stehen darin, etwa „Reagieren auf Veränderung mehr als das Befolgen eines Plans“. Wichtig ist das Wort „mehr“. Das Manifest lehnt Pläne nicht ab. Es gewichtet sie anders.

Viele Teams haben daraus „wir planen nicht mehr“ gemacht. Das ist ein Missverständnis, und es ist teuer. Auch ein agiles Projekt braucht ein Produktziel, ein Budget und eine grobe Release-Planung, wie im Beitrag zur Planung eines Softwareprojekts beschrieben.

Was Studien wirklich belegen

Wenig. In Vorträgen taucht regelmäßig der CHAOS Report der Standish Group auf, der agilen Projekten deutlich höhere Erfolgsquoten bescheinigt als klassischen. Vorsicht damit. Die Rohdaten sind nicht öffentlich, die Erfolgsdefinition wurde 2015 geändert, und Forscher wie Magne Jørgensen oder Chris Verhoef haben die Methodik früherer Ausgaben scharf kritisiert, unter anderem weil die Stichprobe zu gescheiterten Projekten neigen könnte. Dazu kommt ein möglicher Auswahleffekt: Werden agile Verfahren häufiger bei kleineren Vorhaben eingesetzt, verzerrt das den Vergleich, denn kleine Projekte gelingen laut Standish selbst deutlich öfter als große.

Belastbar ist eher die Logik als die Statistik. Je unsicherer die Anforderungen, desto mehr lohnt sich frühes Feedback.

Entscheidungsmatrix: sieben Kriterien

Statt einer Glaubensfrage hilft eine nüchterne Einschätzung. Bewerte für dein Projekt jedes Kriterium:

Wenn fünf oder mehr Zeilen nach rechts zeigen, spricht vieles für ein agiles Vorgehen. Überwiegt links, ist ein klassischer Ablauf vermutlich effizienter. Ein gemischtes Bild ist der Normalfall, und dann ist hybrid die ehrlichste Antwort.

Hybrid: was in der Praxis am häufigsten funktioniert

Viele erfolgreiche Projekte kombinieren beides. Ein bewährtes Muster:

1. Klassische Vorphase mit Zielen, Rahmen, Budget, nicht-funktionalen Anforderungen und Grobarchitektur.
2. Agile Umsetzung in Sprints mit priorisiertem Backlog.
3. Feste Meilensteine für Freigaben, etwa Pilotbetrieb oder Datenmigration.
4. Klassische Abnahme am Ende jedes Release mit dokumentiertem Protokoll.

Das ist kein fauler Kompromiss. Es trägt der Tatsache Rechnung, dass manche Dinge sich nicht iterativ entwickeln lassen. Eine Datenbankarchitektur, die nach drei Monaten umgebaut werden muss, kostet mehr als ein paar Tage Vorab-Design.

Für die öffentliche Verwaltung in Deutschland ist das V-Modell XT der klassische Referenzrahmen. Version 1.0 erschien 2005. Es kennt neben dem sequenziellen Ablauf auch inkrementelle Strategien. Das geht in der Diskussion gern unter. Starr ist oft nicht das Modell, sondern seine Anwendung.

Typische Fehler auf beiden Seiten

Klassische Projekte scheitern oft daran, dass das Lastenheft als Wahrheit behandelt wird, obwohl es eine Hypothese ist. Die Nutzer sehen die Software erst nach Monaten, und dann zeigt sich, dass wesentliche Abläufe anders laufen. Was dann folgt, ist eine Welle von Änderungsanträgen, die man mit einem sauberen Change-Request-Prozess zumindest beherrschbar hält.

Agile Projekte scheitern anders. Es fehlt ein Product Owner mit echter Entscheidungsbefugnis, das Backlog wächst ungebremst, und nach einem Jahr ist das Budget weg, ohne dass ein klares Produkt existiert. Sprints werden zu Ritualen, Retrospektiven zu Pflichtterminen. Agil ohne Disziplin ist teurer als jeder Wasserfall. Das sagt kaum jemand laut.

Ein gemeinsamer Fehler: Das Vorgehensmodell wird gewählt, weil es gerade modern ist oder weil der Dienstleister es immer so macht. Die Entscheidung gehört an den Anfang, bewusst, mit Blick auf die Kriterien oben.

Was das für Budget und Vertrag bedeutet

Agiles Vorgehen und Festpreis vertragen sich schlecht, solange der Umfang fix sein soll. Agiles Vorgehen mit festem Budget und variablem Umfang funktioniert dagegen gut. Die Muss-Anforderungen müssen dann sauber nach MoSCoW priorisiert sein, damit klar ist, was garantiert geliefert wird. Mehr dazu im Vergleich Festpreis oder Time and Material.

Wer sehen möchte, wie ein Studio diese Mischung in eigenen Produkten und Partnerprojekten umsetzt, findet bei OnlineBuilders eine Beschreibung der Arbeitsweise von der Idee bis zum Betrieb.

Nächster Schritt: Geh die Entscheidungsmatrix mit den zwei oder drei wichtigsten Beteiligten durch, jeder für sich. Wo ihr unterschiedlich bewertet, liegt die eigentliche Projektfrage, und die solltet ihr vor dem Kick-off klären.