... oder wie viel Projektmanagement steckt in Scrum
Im ersten Artikel dieser Serie haben wir die agilen Vorgehensweisen, als Methoden zur Umsetzung beschrieben. Das bei der Erstellung des Projektauftrages alle Wissensgebiete des Projektmanagements betrachtet werden, wurde im zweiten Artikel ausführlich dargelegt. Im Projektauftrag werden dann die Weichen gestellt, ob das Projekt mit klassischen (Wasserfall, V-Modell etc.) oder agilen (Scrum, Kanban etc.) Methoden umgesetzt wird.
Klassische Projektumsetzung
In der klassischen Umsetzung gibt es noch die Trennung zwischen Projektplanung, Umsetzung und Steuerung. Der Projektinhalt wird komplett mit Zeitbedarf, Arbeitsaufwand, Abhängigkeiten und Ressourcenbedarf durchgeplant und bewertet. Budgetbedarf und Terminplanung leiten sich also aus der zu verrichtenden Arbeit ab. Jede Änderung in der Umsetzung bedarf einer Neubewertung der Arbeit und damit von Budget und Terminen. Im "magischen Dreieck" des Projektmanagements ist daher der Scope der primäre Parameter und Budget und Termine die sekundären (reaktiven) Parameter.
Agile Projektumsetzung
In der agilen Umsetzung erfolgen Projektplanung, Umsetzung und Steuerung während der gesamten Umsetzungsphase. Diese Aktivitäten finden teilweise in den jeweiligen Iterationen, aber auch unabhängig davon statt. Der Projektinhalt ist durch die Vision und wichtige Anforderungen zu Beginn des Projektes noch nicht umfänglich klar. Oft stehen die Zusammensetzung des Teams und ein Zieltermin mit der Anzahl der Iterationen fest. Im "magischen Dreieck" des Projektmanagements sind hier Budget und Termine die eher fixen Größen und der Scope die variable Komponente.
Wie viel Projektmanagement steckt in Scrum
Am Beispiel von Scrum möchte ich hier auf die Komponenten des (klassischen) Projektmanagements, die in den jeweiligen Prozessen und Aktivitäten umgesetzt bzw. angewandt werden, eingehen.
Das Produktbacklog verändert sich während der gesamten Umsetzung. Die Vision wird in Epics herunter gebrochen und die Epics gehen in umsetzbare und steuerbare User Stories auf. Das erinnert sehr an die WBS (work brakedown structure) bzw. den PSP (Projektstrukturplan). Allerdings handelt es sich hier um einen permanenter Prozess, bei dem die entstandenen Struktur kaum eine Rolle spielt. Zur Steuerung der Umsetzung dient hier die Priorisierung der Themen.
Kennzeichnend für die agile Umsetzung ist die Variabilität bei der Spezifikation und Umsetzung der Themen. Termine und Budgets müssen nicht permanent überprüft werden. Es entsteht kein zusätzlicher Planungsaufwand.
Planung
Im Grooming werden die erstellten User Stories durch den Product Owner dem Team vorgestellt. Das Team schätzt mit dem Planning-Poker die Komplexität der Umsetzung anhand von Referenz-Stories. Wie bei den "klassischen" Schätzverfahren fließen die Erfahrungen des Umsetzungsteams hier ein. Während im "Klassischen" nur die Erfahrungen vergangener Projekte herangezogen werden, fließen bei den "Agilen" auch aktuelle Erkenntnisse vorangegangener Iterationen ein. Im Planning fließen dann Komplexität und Abhängigkeit der Stories sowie Verfügbarkeit der Ressourcen bei der Zusammenstellung des Sprint-Backlogs mit ein.
Umsetzung
Die iterative Umsetzung erfolgt in geschützten Sprints. Dabei ist es die Verantwortung des Scrum Masters und des Teams, Einflüsse und Veränderungen am Sprint-Backlog nicht zuzulassen. Nur mit der Fokussierung auf die festgelegten Themen kann das Team seine Velocity und die gesteckten Ziele aus dem Sprint-Planning erreichen. Im Daily erfolgt die Abstimmung des Teams anhand erreichter Ergebnisse, anstehender Aufgaben und zu lösender Probleme. (Es ist kein Statusbericht!) Mit dem Burn-Down wird verdeutlicht, wo das Team in der Abarbeitung seiner Aufgaben innerhalb des aktuellen Sprints steht.
Steuerung
Zum Abschluss der Iteration werden die umgesetzten Inhalte in Form eines Reviews durch den Product Owner abgenommen und den Stakeholdern vorgestellt. Diese Abnahmen kennen wir auch aus der klassischen Umsetzung, wobei hier dann oft die Flexibilität in der Nacharbeit fehlt. Weiterhin wird durch den Product Owner das Burn-Up aktualisiert. Es zeigt die geplanten und umgesetzten Story Points pro Sprint in kumulierter Form. Dieses Diagramm fließt in die Berichterstattung über den Projektfortschritt ein.
(mehr dazu im nächsten Beitrag 4/5 in dieser Reihe)
Zu jedem Abschluss eines Sprints gehört die Retrospektive des Scrum-Teams. Hier geht es darum, sich über die Erfahrungen aus dem zurückliegenden Sprint auszutauschen, diese zu analysieren und daraus Verbesserungen für die inhaltlichen und organisatorischen Arbeit abzuleiten.
Auch bei der klassischen Umsetzung wird empfohlen, kontinuierlich Lessons Learned durchzuführen. Leider erleben wir das in der Praxis viel zu wenig.
