Home / Agilität / Agilität in Projekten (3/5) – Projektmanagement in Scrum

Agilität in Projekten (3/5) – Projektmanagement in Scrum

Michael Wegge

Gründer und Geschäftsführer der RUHR PM GmbH

... oder wie viel Projektmanagement steckt in Scrum

Im ersten Artikel dieser Serie haben wir etwas provokant "warum es kein agiles Projektmanagement gibt" 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 "magische Dreieck" des Projektmanagements ist daher der Scope der primäre Parameter und Budget und Termine die sekundären (reaktiven) Parameter.

Projektumsetzung klassisch

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.

Projektumsetzung agil

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 des 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.

Dem Thema "Lessons Learned" widmen wir uns im letzten Beitrag 5/5.


Erfahren Sie mehr in unseren PM-Nuggets

... das Business Breakfast mit interessanten Vorträgen und Workshops zur Agilität und zum Projektmanagement in der Digitalisierung.

Informieren Sie sich über unsere PM-Workshops

... als Einstieg für ihr Unternehmen bei der Einführung von agilen Methoden und wie Projekte einfach erfolgreich werden.


Wenn Ihnen der Beitrag gefallen hat, teilen Sie ihn hier auf den Kanälen Ihrer Wahl:


Letzte Beiträge dieser Kategorie

Kommentare

Schreiben Sie einen Kommentar

Google Analytics Opt-Out Cookie wurde erfolgreich gesetzt.

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Website stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Akzeptiert