Der iterative Wasserfall (ist nicht agil)

Bild: Wikimedia Commons/Sergey Ashmarin - CC BY-SA 2.0

Ein paar Gedanken zum iterativen Wasserfall, den Mike Cohn auf seinem Blog als agiles Antipattern vorgestellt hat.

Zum Verständnis zuerst die Erklärung was das ist: Der iterative Wasserfall ist eine Ausformung von ScrumBut, d.h. falsch verstandener Agilität. Das grundsätzliche Missverständnis besteht in dem Glauben, dass man nur alles in Form von User Stories formulieren und die im Sprint-Rhythmus von zwei bis vier Wochen erledigen müsste. Dann wäre man agil. In der Realität führt das dazu, dass eigentlich zusammengehörende Prozesse auseinandergerissen und separat erledigt werden. Zum Beispiel gibt es in Sprint 1 die Story "Als Product Owner möchte ich detaillierte User Stories für die nächsten Sprints schreiben, damit das Entwicklungsteam sie nur noch abarbeiten muss". Im 2. Sprint wird eine der so entstandenen Stories von den Entwicklern umgesetzt, im 3. folgt eine neue Story namens "Als Tester möchte ich die User Story des letzten Sprints testen um sicherzustellen, dass sie funktioniert wie vorgesehen". Gegebenenfalls kommen noch weitere "fachspezifische" Sprints dazu, etwa für Oberflächen-Design, getrennte Frontend/Backend-Entwicklung oder Regressionstest.

Dieses Vorgehen ist, wie Cohn richtig schreibt, weder Scrum noch agil. Stattdessen wird lediglich der bestehende Wasserfall-Prozess genommen und in viele kleine Wasserfälle unterteilt, die dann jeweils drei bis X Sprints dauern können. In der Praxis begegnet man diesem Vorgehen immer wieder, vor allem dort wo Scrum neu eingeführt wird. Zum Teil sind sich die Beteiligten gar nicht bewusst, dass sie die Methode gerade verhunzen, zum Teil machen sie es aber auch mit voller Absicht. Beliebte Begründungen sind in dem Fall, dass man Scrum "verbessert" oder "angepasst" hätte, oder aber "dass es in unseren Unternehmensstrukturen nicht anders geht". Letzteres kann zum Beispiel damit begründet werden, dass POs, Tester oder Entwickler parallele Linienaufgaben haben, die sie in periodischen Abständen ganz aus dem Projekt herausziehen. In diesem Fall stehen sie nur jeden zweiten oder dritten Sprint zur Verfügung, weshalb ihre Aufgaben hierher "verschoben" werden.

Problematisch wird dieses Vorgehen dadurch, dass das Erfüllen einer Definition of Done kaum noch möglich ist. Dass die User Stories vor dem Sprint erstellt werden kann noch sinnvoll sein (so lange sie gegroomt werden und nicht zu Feinspezifikationen ausarten), danach hört es aber auf. Ein Sprint in dem nur eine Benutzeroberfläche ohne Backend erstellt wird oder an dessen Ende eine "fertig entwickelte" aber nicht getestete Komponente steht liefert eben keinen "shippable Code", wie es eigentlich vorgesehen ist. Stattdessen ergibt sich fast zwangsläufig die Notwendigkeit, angeblich "fertige" Features wieder anzufassen und Nacharbeiten durchzuführen. Bedingt dadurch steht immer wieder in den Sprints weniger Zeit für die neuen Stories zur Verfügung als gedacht, wodurch diese nicht fertig und die Sprintziele verfehlt werden. Am Ende steht das gleiche Chaos, das man aus dem "Fast tracking" in Wasserfallprojekten kennt.

Es ist aus diesen Gründen sehr zu empfehlen, dem Entstehen eines iterativen Wasserfalls von Beginn an entgegenzuwirken. Sobald er sich einmal etabliert hat ist er mitunter nur sehr schwer wieder abzuschaffen.