Agiles Projektmanagement mit Scrum

Der Ansatz des agilen Projektmanagements lässt sich sehr gut mit Scrum kombinieren. Die Rollen, Meetings und Verantwortungen aus Scrum werden dabei 1 zu 1 übernommen. Allerdings ergänzen wir Scrum mit Werkzeugen aus dem agilen Projektmanagement und nehmen das Project Inception und die Projektbeauftragung hinzu.

Der Scrum-Zyklus verändert sich ein wenig uns sieht wie im folgenden Beispiel aus:

img_20161028_123257

Vision

Der Auftraggeber (z.B. CEO, Marketingchef, externer Kunde) hat eine Produktvision und kommt mit dieser Vision zum Projektteam, um über die Machbarkeit zu diskutieren.

Project Inception

Es wird ein erstes Projektteam gebildet, z.B. aus Scrum Master, Product Owner und einem oder zwei Entwickler mit genügend Wissen für eine erste Analyse der Vision.
Die Vision wird näher betrachtet und das Projektteam fertigt ein Project Inception an. Mit dem Auftraggeber werden Rahmenbedingungen wie die Priorität von Umfang/Qualität/Budget/Zeit bestimmt und eine erste Generierung der Backlog Items geschieht. Je nachdem in wie weit der Kunde in den Prozess mit eingebunden werden kann (und möchte), wird entschieden, ob in dieser Phase bereits eine umfangreiche Aufwandsschätzung zu erfolgen hat. In dem Fall wird bereits frühzeitig das Projektteam erweitert, so dass die Aufwandsschätzung von den Team-Mitgliedern durchgeführt wird, die an dem Projekt auch arbeiten werden.
Sobald die Rahmenbedingungen für das Projekt festgelegt worden sind, erfolgt eine schriftliche Genehmigung des Projekts durch den Auftraggeber. Dies stellt den Startschuss für das Projektteam dar.

Backlog füllen

Die erste Aufgabe wird es sein, das Backlog mit weiteren Backlog Items zu füllen. Das Team wird sich dabei zunächst auf der Ebene von Master Stories bewegen und nur nach und nach die User Stories dazu erstellen.
Das Füllen wird in einem oder mehrere Sprints durchgeführt. Dazu werden vor allem SPIKES angewendet, um eine Analyse der Requirements durchzuführen.

Vorbereitung zu Sprint 1

Im Rahmen des Füllens des Backlogs wird auch der erste Sprint vorbereitet. Dazu werden die User Stories identifiziert, die für den Projektstart erforderlich sind und bereits detaillierter beschrieben und geschätzt. Umso mehr User Stories zur Wahl für Sprint 1 stehen, desto besser. Allerdings sollte auch diese Phase zeitlich begrenzt sein, um nicht zu viel Zeit auf die Planung anzuwenden. Die weitere Planung wird im Laufe der Projektumsetzung parallel zur Entwicklung des Produktes erfolgen.

Der Sprint-Zyklus beginnt

Ab jetzt arbeitet das Scrum-Team wie gewohnt an den User Stories aus dem Product Backlog. In den Estimation Meetings werden nach und nach die noch nicht als User Stories heruntergebrochenen Master Stories besprochen und User Stories generiert sowie geschätzt.

Parallel dazu: die Roadmap

Während das Scrum-Team mit Sprint 1 beginnt, wird der Product Owner die bereits zur Verfügung stehenden Master Stories in die Roadmap und einen Releaseplan übertragen. Beide Pläne werden im Sprint-Zyklus kontinuierlich aktualisiert.

Das Produkt entsteht inkrementell

Das Scrum-Team hat weiterhin das Ziel, am Ende jedes Sprints einen releasbaren Stand des Produktes zu haben. Im Projekt werden neue Releases allerdings anhand des Releaseplans abgebildet, weshalb sich das Release am Sprintende vermutlich auf eine neue testbare Version beschränken wird. Vielleicht hat das Team ein Demosystem für den Auftraggeber aufgesetzt, auf das am Sprint-Ende der jeweils aktuelle Stand eingespielt wird.
Sobald das Projekt abgeschlossen ist, bekommt der Auftraggeber das fertige Produkt ausgeliefert.

Dank vieler Releases in der Zwischenzeit und kontinuierliches Feedback durch den Auftraggeber, wird das Produkt am Ende keine Überraschung für den Auftraggeber sein und ein für Scrum-Team und Auftraggeber zufriedenstellendes Ergebnis darstellen.

Meetings im Scrum-Prozess

Meetings im Scrum-Prozess

Estimation

In regelmäßigen Abständen findet ein sog. Estimation Meeting statt, um neue Stories zu schätzen oder bereits geschätzte Stories nochmals zu schätzen. Das Ziel, diese Schätzungen in einem regelmäßig stattfindenden Meeting durchzuführen, liegt darin, dass das Team während des Sprints so nicht in seiner Arbeit unterbrochen wird.
Das Estimation Meeting dient dem Product Owner einzuordnen, wie komplex eine Aufgabe ist und er erhält Rückmeldung darüber, ob noch weitere Informationen von ihm oder dem Kunden benötigt werden, um eine Story zu schätzen bzw. im nächsten Sprint anzugehen. Der Product Owner überträgt die Schätzungen in die Stories in dessen Produkt-Backlog und lässt Schätzungen ggf. bei der Priorisierung mit einfließen.

  • Üblicherweise wird ein Estimation Meeting pro Sprint durchgeführt
  • Die Moderation übernimmt der Product Owner
  • Alle Team-Mitglieder schätzen die Stories
  • Eine Meeting-Dauer von 30 bis maximal 90 Minuten sollte angestrebt werden

Sprint Planning 1

In diesem Meeting stellt der Product Owner eine Reihe von Stories aus seinem Produkt-Backlog vor, die er im nächsten Sprint umgesetzt haben möchte. Im Dialog mit dem Team werden die Möglichkeiten zur Umsetzung der Stories erörtert, fehlende Angaben ergänzt und das Team übernimmt Stories in das Sprint-Commitment. Der Scrum Master moderiert das Meeting und hilft somit dem Product Owner, dessen Stories zu präsentieren und dem Team, den Inhalt des nächsten Sprints zu definieren.

Das Sprint Planning 1 stellt die Weichen für das Sprint-Commitment, also der Verpflichtung von Product Owner und Team, das gemeinsame Ziel des nächsten Sprints zu erreichen.

Sprint Planning 2

Die im Sprint Planning 1 durch das Team aufgenommene Stories, werden im Sprint Planning 2 im Detail durchgesprochen und Aufgaben generiert. In diesem Meeting, in dem nur das Team und der Srum Master teilnehmen, wird das endgültige Commitment, also die Auswahl an Stories, die das Team im nächsten Sprint umsetzen möchte, aufgestellt. Sowohl das Sprint Planning 1, als auch das Sprint Planning 2 finden direkt am Start eines neuen Sprints statt.

Am Ende des Meetings erstellt das Team zusammen mit dem Scrum Master eine Liste aller Sprint-Aufgaben und überreicht sie dem Product Owner.

Sprint Review

Im Sprint Review stellt das Team die Ergebnisse des Sprints vor und es erfolgt eine Abnahme durch den Product Owner. Im Optimalfall sind in diesen Meetings auch die Kunden anwesend, um neue Funktionalitäten direkt präsentiert zu bekommen. Mit Hilfe dieses Meetings wird überprüft, ob das gemeinsame Sprint-Ziel erreicht werden konnte. Dabei erfolgt keine schlichte Präsentation des Standes, sondern die Funktionalität wird in der Software vorgeführt.
Neben dem Team, Scrum Master und Product Owner, können auch Gäste und Interessiert an diesem Meeting teilnehmen und sich über den aktuellen Stand informieren.
Üblicherweise findet das Sprint Review am Ende eines Sprints statt und sollte maximal 90 Minuten dauern.

Sprint Retrospective

In diesem Meeting wird der Verlauf des letzten Sprints diskutiert. Ergebnisse werden besprochen, Punkte, die es in Zukunft zu verbessern gilt, evaluiert und ein Aktionsplan entworfen. Oftmals ist es der Scrum Master, der mit neuen umzusetzenden Aufgaben aus diesem Meeting herausgeht. Aber auch das Team generiert sich im Rahmen dieses Meetings Aufgaben, die zumeist parallel zum täglichen Geschäft durchgeführt werden. Insbesondere im Hinblick auf Verbesserungen in den Team-internen Arbeitsabläufen, Kommunikation mit dem Product Owner, dem Einhalten der Team-Regeln usw.

Scrum-of-Scrum

Bestehen in einer Organisation mehrere Teams, kann der Austausch zwischen diesen Teams mittels dieses Meetings stattfinden. Dabei treffen sich Vertreter der jeweiligen Teams einmal pro Tag und berichten über aktuelle Hindernisse und den Fortschritt des Sprint Backlogs. Besonders Sinnvoll ist diese Art von Austausch, wenn es viele Abhängigkeiten zwischen den Teams gibt und eine häufige Synchronisation notwendig ist.

Daily Scrum

Dieses Meeting findet täglich außer am ersten Tag des Sprints statt. Das Meeting ist vom Team für das Team. Die einzelnen Team-Mitglieder berichten dabei abwechselnd in wenigen Sätzen vom bisherigen Fortschritt, was als nächstes gemacht wird und über etwaige Hindernisse. Das Meeting besteht also aus:

  • Was habe ich gestern gemacht?
  • Was mache ich heute?
  • Was hindert mich daran, die gesteckten Ziele zu erreichen?

Aufkommende Hindernisse werden vom Scrum Master aufgenommen und in das Impediment Backlog eintragen.
Normalerweise findet dieses tägliche Meeting früh morgens und in der Nähe der Aufgabentafel (auch Taskboard genannt) statt. Es handelt es sich um ein time-boxed Meeting, das maximal 15 Minuten dauern sollte und soll dem Team dabei helfen, die Arbeit zu planen und sich selbst zu organisieren.

Typischerweise bestehen die Regeln des Meetings aus:

  • Das Meeting wird vom gesamten Team durchgeführt
  • Die Dauer beträgt maximal 15 Minuten
  • Es findet jeden Tag zur gleichen Zeit und am gleichen Ort statt
  • Zuschauer sind erlaubt, dürfen sich aber nicht aktiv am Meeting beteiligen
  • Das Meeting dient zum Aufdecken von Problemen, aber nicht zur Lösungsfindung
  • Ein Team-Mitglied oder der Scrum Master moderieren das Meeting