Ein iterativer Wasserfall ist nicht agil

In den letzten zwei Jahren ist mir ein beunruhigender Trend aufgefallen – und zwar bei Teams in allen Teilen der Welt.

Es ist die Tendenz, einen iterativen Wasserfallprozess zu erschaffen und diesen dann „agil” zu nennen.

Ein iterativer Wasserfall

In einem Sprint versucht jemand (vielleicht ein Business Analyst zusammen mit dem [Product Owner](/de/product-owner/ "Product Owner)), herauszufinden, was entwickelt werden soll.

Weil man agil sein möchte, wird mit User Stories gearbeitet. Aber anstatt die User Stories als Platzhalter für spätere Gespräche zu behandeln, wird jede User Story zu einem kleinen Spezifikationsdokument von drei bis fünf Seiten Inhalt – und ich habe durchaus schon längere gesehen.

Diese Mini-Spezifikationen/User Stories dokumentieren fast alles, was einem dazu in den Sinn kommen kann.

Weil man einen ganzen Sprint benötigt, um das alles herauszufinden und zu dokumentieren, wird ein zweiter Sprint dem Design für das User Interface der User Story gewidmet. Manchmal versucht das Team, ein wenig agiler zu sein (zumindest gedanklich) und beginnt mit der Designarbeit schon kurz bevor die Mini-Spezifikation für eine User Story vollständig geschrieben ist.

Viele Teammitglieder sehen das als gefährlich an, weil die Spezifikationen noch nicht vollständig erfasst sind. Aber was soll’s, dann kommt an diesem Punkt eben die Agilität ins Spiel.

Die Programmierer bekommen dann zwei Dokumente in die Hand gedrückt. Das eine zeigt klar und deutlich, wie die User Story am Ende aussehen soll, und das andere liefert alle relevanten Details zum Verhalten der Story.

Man kann erst mit dem Programmieren anfangen, wenn diese beiden Artefakte fertig sind. In einigen Unternehmen sind es die Programmierer, die diese Arbeitsweise forcieren. Sie haben die Einstellung, alles zu entwickeln, was man will – man sollte ihnen aber besser zu Anfang des Sprints ganz genau sagen, was benötigt wird.

Einige Organisationen gehen sogar noch einen Schritt weiter und lassen die Tester eine Iteration hinter den Programmierern arbeiten. Das passiert scheinbar, weil die User Stories eines Teams größer werden, wenn jede Story über eine Mini-Spezifikation und ein vollständiges UI-Design verfügen muss, bevor Code geschrieben werden kann.

Glücklicherweise ist den meisten Teams klar, dass Programmierer und Tester in der gleichen Iteration zusammenarbeiten müssen, jedoch weiten sie diese Theorie das nicht auf ein ganzes zusammenarbeitendes Team aus.

Das führt zu dem folgenden Prozess

Eine erste Iteration wird der Analyse gewidmet. Eine zweite Iteration (die sich ggf. leicht mit der ersten überschneidet) wird dem User Experience Design gewidmet und die dritte Iteration ist zum Codieren und Testen gedacht. Das ist nicht agil. Es könnte der erste Schritt einer Organisation sein, agil zu werden. Es ist aber nicht agil.

Es ist ein iterativer Wasserfall.

Bei der traditionellen Entwicklung mit Wasserfall erledigt ein Team die gesamte Analyse für das gesamte Projekt ganz zu Anfang. Dann wird das gesamte Design für das Projekt in Angriff genommen. Dann wird der Code für das gesamte Projekt geschrieben. Dann werden alle Tests für das Projekt durchgeführt.

In dem eben beschriebenen iterativen Wasserfallprozess macht das Team es im Grunde genauso, allerdings wird jede Story wie ein eigenes kleines Projekt behandelt. Erst wird die gesamte Analyse für die Story abgeschlossen, dann das Design für diese Story, dann wird der gesamte Code geschrieben und alles getestet. Das ist ein iterativer Wasserfall-Prozess, kein agiler Prozess.

In einem agilen Prozess würden idealerweise alle Arbeiten zu genau dem gleichen Zeitpunkt fertiggestellt. Das Team würde also zur gleichen Zeit mit der Analyse des Problems und mit dem Design für die Lösung des Problems fertig sowie mit dem Code und den Tests für diese Lösung. Alle vier Disziplinen (und andere, auf die ich in diesem Beispiel nicht eingegangen bin) würden also exakt zur selben Zeit fertig sein.

Es ist etwas naiv, zu glauben, dass man das zu 100 % erreichen kann. (Manchmal kann man das schaffen.) Es kann jedoch ein Ziel sein, auf das ein Team hinarbeitet.

Ein Team sollte immer versuchen, so viel Arbeit wie möglich gleichzeitig zu erledigen. Alle Überlegungen, die man vorab anstellt (Analyse, Design etc.) sollten so spät wie möglich angestellt werden, nicht sonderlich detailliert sein und es gleichzeitig möglich machen, dass die Arbeit während der Iteration fertiggestellt werden kann.

Wenn Sie Ihre User Stories wie kleine Spezifikationsdokumente behandeln, hören Sie damit auf. Fangen Sie stattdessen an, jede Story als Platzhalter für eine Unterhaltung zu sehen.Sie können die Stories gerne mit einigen Anmerkungen zu Dingen versehen, die Sie bei der nächsten Besprechung nicht vergessen möchten. Diese Anmerkungen sollten aber optional sein und kein notwendiger Schritt in einem sequenziellen Prozess. Das erhält die Agilität und verhindert, dass der Prozess zu einem Wasserfall wird.

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.

Certified Scrum Product Owner Training

Wenn du herausfinden willst, wie du einen iterativen Wasserfall verhindern kannst und wie agile Produktentwicklung aussieht, besuch eins unserer Certified Scrum Product Owner Trainings.

Stakeholdermanagement

=> Lerne die wichtigsten Tipps & Tricks von Roman Pichler zum Stakeholdermanagement

Definition of Done: simpel und doch komplex

=> Finde heraus, wie dir die Definition of Done bei der agilen Arbeit hilft.

Wie läuft eine Sprint Review ab?

=> Hier findest du eine beispielhafte Agenda für das Sprint Review