Projektmanagement Wasserfall vs. agile Umsetzung

Als Projektmanager*in hört man immer häufiger den Satz: „Können wir das nicht agil umsetzen?“ Klar, können wir. Aber was das konkret für die Projektumsetzung bedeutet und welche Vorteile und/oder Nachteile die agile Entwicklung hat, ist selten so klar. Viel Spaß beim Lesen!

Die Umsetzung eines Projekts nach dem Wasserfallmodell findet linear oder auch sequenziell statt. Das heißt, die einzelnen Prozessschritte werden nacheinander abgearbeitet. Nach jedem Arbeitsschritt werden die Ergebnisse überprüft und vom Kunden abgenommen und freigegeben. Erst dann geht’s weiter zum nächsten Schritt.

Ein Wasserfall-Projekt ist nichts ohne ein Lastenheft und ein Pflichtenheft. Das Lastenheft ist der Katalog an Anforderungen, die der Auftraggeber stellt; das Pflichtenheft hält daraufhin fest, wie diese Anforderungen erfüllt werden sollen.

Gehen wir als Beispiel-Projekt mal von der Entwicklung einer App aus. Die Umsetzung nach dem Wasserfallmodell würde in etwa die folgenden Schritte umfassen:

1. Anforderungskatalog (Lasten –und Pflichtenheft)
2. Konzeption
3. Design
4. Erstellung eines Prototyps (Proof of concept)
5. Technische Umsetzung (ggf. inkl. Schnittstellen)
6. Testing
7. Dokumentation
8. Auslieferung
9. Wartung/Support

Dieser Zyklus beginnt für jede Entwicklungsphase („Version 1“, „Version 2“, etc.) aufs Neue. Ein Vorgehen nach dem Wasserfallmodell eignet sich besonders dann, wenn seitens des Auftraggebers schon eine sehr genaue Vorstellung des finalen Produkts vorliegt und es nach jeder Phase der Entwicklung im Einsatz überprüft werden kann.

Den vertraglichen Rahmen für dieses Vorgehen bildet ein Werksvertrag. Änderungsanforderungen fließen über „Change Requests“ in das Projekt ein.

• Planbarkeit und Kontrolle (klarer Zusammenhang zwischen Leistung und Kosten).
• Bekanntes Vorgehen („keine Experimente“).
• Klare Abgrenzung der einzelnen Schritte.
• Von Anfang an gemeinsames Verständnis über das abzuliefernde Werk (durch Lasten- bzw. Pflichtenheft).
• Zuarbeit des Auftraggebers ist nur in der Konzeptionsphase nötig.
• Hinter dem Wasservorhang liegt höchstwahrscheinlich eine Höhle mit Piratengold verborgen.

• Unflexibel gegenüber Änderungen und im Vorgehen.
• Die Leistungsbeschreibung wird zu Beginn des Projekts festgelegt. Zu diesem Zeitpunkt ist das Projekt nicht immer komplett überschaubar. Gerade bei länger laufenden Projekten kann das dazu führen, dass das Produkt bei Fertigstellung schon veraltet ist. Außerdem kommt es im Laufe des Projekts erfahrungsgemäß zu einer Vielzahl von Änderungsanforderungen.
• Diese Änderungsanforderungen erhöhen den zeitlichen und finanziellen Rahmen des Projekts. Wenn es viele Änderungsanforderungen gibt, kann der Fokus auf die eigentliche Zielsetzung des Projekts abhandenkommen.
• Fehlentwicklungen fallen erst sehr spät im Projekt auf.
• Die Konzeptionsphase kann bei unkonkreten Vorgaben einen langen Abstimmungsprozess beinhalten.
• Ein fertiges Produkt steht erst am Ende der Umsetzung zur Verfügung. Die Akzeptanz und somit der Erfolg des Produkts kann erst dann überprüft werden.

Das agile Modell nähert sich schrittweise der Lösung an und verbessert das Produkt im Laufe der Entwicklung kontinuierlich. Kurz und kompliziert: Es verfolgt einen iterativen und inkrementellen Ansatz. Wichtig ist hier, dass die einzelnen Schritte fließend ineinander übergehen und teilweise parallel stattfinden. Zwischenergebnisse können dabei die Basis für den folgenden Arbeitsschritt darstellen, d.h. Kurskorrekturen sind nahezu immer möglich.

Die agile Umsetzung erfolgt in sogenannten Sprints. Das sind festgelegte Zeiteinheiten für eine Entwicklungsphase; sie umfassen meist 2–4 Wochen. Zu Beginn jedes Sprints werden Zielsetzungen festgelegt. Jede Phase beinhaltet Konzeption, Umsetzung, Testing und Dokumentation für das umzusetzende Teilprodukt, für jeden Sprint können deswegen Prioritäten neu gesetzt werden. Nach Abschluss eines Sprints wird der erreichte Zwischenstand evaluiert.

Der Prozess sieht also so aus:

• Sprint 1 (Konzeption, Umsetzung, Testing, Dokumentation, Evaluation)
  • Sprint 2 (Konzeption, Umsetzung, Testing, Dokumentation, Evaluation)
    • Sprint 3 (Konzeption, Umsetzung, Testing, Dokumentation, Evaluation)
      • ...

Daraus ergibt sich auch ein flexibler Umgang mit Änderungsanforderungen seitens des Auftraggebers während der Entwicklungszeit. Vor allem bei Projekten mit einer längeren Laufzeit von mehreren Monaten ist davon auszugehen, dass sich Rahmenbedingungen, Umsetzungswünsche und Prioritäten im Laufe des Projekts ändern.

Eine agile Entwicklung eignet sich besonders dann, wenn das Projekt zu Anfang noch nicht ganz klar umrissen werden kann oder soll. Hier entwickelt sich die finale Zielsetzung während des Projektverlaufs.

Einem agilen Projekt liegt ein Dienstvertrag zugrunde. Der Auftraggeber bestellt beim Auftragnehmer einen Zeitrahmen mit maximalen Entwicklungsaufwänden.

• Anforderungsänderungen können jederzeit reibungslos in den Umsetzungsprozess übernommen werden und lösen keine Change Requests aus.
• Das Produkt entwickelt sich im Dialog zwischen Auftraggeber und Auftragnehmer und kann jederzeit an geänderte Rahmenbedingungen, Anforderungen oder Prioritäten angepasst werden. Der Auftraggeber ist also regelmäßig in den Entwicklungsprozess involviert.
• „Fast to fail“-Prinzip: Fehlentwicklungen werden frühzeitig erkannt, weil die Umsetzung nach jedem Sprint gemeinsam bewertet wird.
• Man kommt schnell zu einem ersten Ergebnis, Konzeptions- und Abstimmungsphasen verflachen sich, die Entwicklung priorisierter Features wird kompakter.
• Das Endprodukt entspricht besser den tatsächlichen Bedürfnissen des Auftragnehmers, da die Anforderungen im Laufe des Projekts kontinuierlich korrigiert und angepasst werden können.

• Es liegt kein Lasten- und Pflichtenheft vor, welches das gemeinsame Verständnis des Endprodukts festlegt. Der Auftragnehmer schuldet kein zu Beginn definiertes Werk, sondern das Volumen des Entwicklungsprozesses.
• Stärkere Zuarbeit und größere Involvierung seitens des Auftraggebers ist nötig.

Generell kann man sagen, dass es nicht DIE Methode gibt, die sich für alle Projekte eignet. Bei der Entscheidung für ein Modell spielen viele Faktoren eine Rolle. Welches Vorgehen zum Einsatz kommt, sollte die Agentur mit dem Auftraggeber gemeinsam vor Projektbeginn entscheiden. Am Ende müssen sich beide mit der vereinbarten Methode wohlfühlen und sich über die jeweiligen Einschränkungen und Auswirkungen bewusst sein.

Folgende Tabelle gibt einige Anhaltspunkte für eine Entscheidung zwischen den beiden Methoden.