Ein Praxisbericht
Aus unserer Beratungserfahrung soll anhand eines praktischen Beispiels erläutert werden, mit welchen Herausforderungen ein Projektteam konfrontiert ist, wenn agile Methodiken auf Wasserfall-Vorgehensweisen treffen.
Ausgangslage
Im Rahmen eines größeren Softwareentwicklungsprojektes wurden fünf Scrum-Teams und zwei Teams mit Wasserfall-Vorgehensweisen eingesetzt. Eine komplette Umstellung auf eine einheitliche agile Methodik hatte sich nicht angeboten, weil die beiden Teams mit Wasserfall-Vorgehensmethodik in ihren Entwicklungen auf externe Lieferanten mit festen Releasezyklen (Basis-Standard-Softwaremodule) dieser Lieferanten basierten.
Das Gesamtprojekt hatte als Zielvorgabe einen gemeinsamen Zieltermin einzuhalten, da das Projekt einen Service für Endkunden im Massenmarkt zur Verfügung stellen sollte.
Herangehensweise
Statt komplett auf Scrum umzustellen, wurden von der Gesamtprojektleitung einzelne Scrum-Element mit bisher üblichen, eher alt bekannten Projektmanagement-Methoden nach PMI kombiniert.
Die Inhalte der Scrum-Teams wurde in einem Arbeitspaket geführt, während die beiden Teams mit Wasserfall-Vorgehensweise als getrennte Arbeitspakete behandelt wurden. Jedem Arbeitspaket wurde ein Arbeitspaket-Verantwortlicher vorangestellt, der auf die erfolgreiche Erbringung der Leistungen und Lieferungen geachtet und dem Gesamtprojektteam wöchentlich berichtet hat.
Darüber hinaus hatte das Gesamtprojektteam ein tägliches Meeting etabliert, welches an ein Daily Scrum erinnert. Hierin wurden die täglichen Aufgaben im Gesamtprojekt abgestimmt und Hindernisse besprochen – auch diejenigen der Teams mit Wasserfall-Vorgehensweise.
Um nun auch planerisch den Überblick zu behalten, wurden sogenannte Iterationen aus Gesamtprojektsicht definiert, welche festgelegte Anteile bezogen auf die Software-Komponenten, Dokumentationen usw. beinhalteten. Mit den Teams mit Wasserfall-Vorgehensweise war die Festlegung, welche Teile in den jeweiligen Iterationen bereitgestellt werden einfach. Mit den Scrum-Teams wurden die User-Stories im Refinement besprochen und nach dem Planning in die Iterationen eingeplant.
Die Scrum-Teams hatten zudem noch eine besondere Herausforderung: es sollten zusätzliche Lieferleistungen für andere Projekte bereitgestellt werden. Das Gesamtprojekt etablierte einen wöchentlichen Austausch im Rahmen des Product-Owner-Boards, welches dann flexibel Entscheidungen treffen konnte.
Nach den Iterationen wurden mit den Stakeholdern Review-Meetings durchgeführt, deren Ergebnisse in die nächste Iteration einfließen konnten. Selbstverständlich wurde auch im Gesamtprojekt vorher definiert, wann eine Iteration als abgeschlossen galt („Definition of Done“).
Sobald sich Veränderungen an den ursprünglichen Planungen ergaben, musste auch das Gesamtprojekt flexibel genug aufgestellt sein, um auf diese Änderungen einzugehen.
Dies wurde dadurch erreicht, dass das Gesamtprojekt ebenfalls tägliche Meetings zur Steuerung durchführte. Darüber hinaus war es unbedingt erforderlich, dass die Stakeholder oder der Lenkungsausschuss kurzfristig über sich ändernde Rahmenbedingungen oder Entscheidungsnotwendigkeiten informiert und einbezogen wurden. Dies verlangte auch von den Stakeholdern eine entsprechende Flexibilität und Verfügbarkeit.
Um am Ende des Projektes auch eine abschließende Sicherheit über die gesamte Funktionsfähigkeit der Software-Komponenten und des Service in Richtung Endkunde zu erhalten, wurde neben der Qualitätssicherung im Rahmen der einzelnen Arbeitspakete bzw. Teams auch ein finaler Produkttest zur Verifikation eingeführt. Dieser hatte zwar keine neuen Erkenntnisse über Fehler aufgezeigt, aber wohl Probleme in den Konfigurationen der komplexen Systeme offengelegt.
Fazit
Die Vermischung von unterschiedlichen Methodiken und Vorgehensweisen – insbesondere Agil und Wasserfall – ist unter Beachtung bestimmter Rahmenbedingungen und einem ebenfalls gemischten Vorgehen im Gesamtprojektmanagement möglich.
Wichtig ist, die Grenzen der Flexibilität bereits im Vorfeld zu kennen. Sie werden in der Regel durch die Teams oder externen Lieferanten bestimmt, die nach dem Wasserfall-Modell vorgegangen sind.