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.

Die Aufgaben von Scrum Master und Product Owner

Wenn Scrum oder andere Prozesse in einem Unternehmen eingeführt werden, dann ist es sehr hilfreich, wenn die Rollen klar definiert werden. Es muss klar herausgestellt werden, wer für was verantwortlich ist und zu wem jemand gehen muss, um eine(n) Lösung/Antwort/Denkanstoß zu erhalten. In Scrum gibt es im Wesentlichen drei Rollen: Scrum Team (oder auch Scrum Developer genannt), Product Owner und Scrum Master.
Hier eine kurze Auflistung der Aufgaben von Scrum Master und Product Owner, die typischerweise von diesen Rollen übernommen werden.

Product Owner:

  • bereitstellen/vermitteln der Vision
  • vorbereiten des Sprint-Inhaltes
  • Priorisierung der Aufgaben
  • erstellen einer Roadmap
  • Pflege des Backlogs
  • Verantwortlich für das Produkt
  • Inhaltliche Verantwortung
  • Beratung des Kunden
  • Kundenkontakt
  • Übersetzer (von den Anforderungen des Kunden in die Entwicklersprache)
  • erstellt User Stories
  • beschreibt Anforderungen
  • hat Budger-Verantwortung
  • für die Abnahme am Sprint-Ende durch / Produkt-Abnahme
  • holt Kundenfeedback ein

Scrum Master:

  • sorgt dafür, dass Scrum funktioniert
  • setzt sich für die Organisationsentwicklung ein
  • hilft bei der Organisation im Team
  • führt eine kontinuierliche Prozess-Optimierung durch
  • stimmt sich mit anderen Scrum Mastern ab
  • sorgt für die Abstimmung mit anderen Teams
  • pocht auf Regeln und Meetings
  • unterstützt den Product Owner bei Bedarf
  • moderiert Meetings
  • Schutzschildfunktion (schützt das Team vor äußeren Störfaktoren)
  • Bindeglied zum Product Owner
  • das gute Herz des Teams
  • fordert Dokumentation ein und erstellt ggf. Meeting Minutes
  • beseitigt Hindernisse (und deckt sie ggf. auf)
  • beschafft Informationen/Räume/Material

Seminar-Angebot: Agiles Projektmanagement am Beispiel von Scrum

Nachdem der Kurs Agiles Projektmanagement am Beispiel von Scrum bereits 2014 erfolgreich stattgefunden hat, wird es auch in diesem Jahr wieder ein Seminar zum Thema agiles Projektmanagement an der VHS Wiesbaden geben.

Mo. 04.05.2015 – Fr. 08.05.2015 und
Mo. 12.10.2015 – Fr. 16.10.2015 (jeweils von 09:00 bis 16:00 Uhr)

Weitere Informationen zu den beiden Lehrveranstaltungen gibt es unter:

Sie werden in diesem Kurs unter Anderem erfahren, was es mit folgendem Konstrukt auf sich hat:
IMG_20141117_103351

 

 

Das Duplo-Baustein-Spiel um Scrum spielerisch zu lernen und zu erleben

Scrum spielerisch erlernen

Um Scrum spielerisch zu erlernen und zu erleben, bieten sich eine Reihe von Methoden an, die unterschiedliche Ziele verfolgen. Besonders im Hinblick auf die Einarbeitung von neuen Mitarbeitern, die ggf. selbst nicht mit Scrum arbeiten, aber im Kontakt mit den Scrum-Teams stehen werden (z.B. ein neuer Mitarbeiter in der Marketing-Abteilung), bietet sich die Duplo-Bausteinen-Variante an, um einen schnellen Überblick über Scrum zu geben.
Dabei wird zunächst in kurzen Sätzen erklärt, um was es in Scrum geht, wieso Scrum im Unternehmen eingesetzt wird und was die Ziele von Scrum im Unternehmen sind. Bei vielen Teilnehmern, werden mehrere Gruppen gebildet, so dass eine Gruppe aus ca. 5 Personen besteht. Die Gruppen bekommen diverse Aufgaben gestellt, die mit Hilfe von Duplo-Bausteinen zu bewältigen sind. Der Moderator kann die Rolle des Product Owners oder die des Kunden einnehmen und liefert bei Fragen zur Umsetzung Hinweise. Jede Gruppe stellt einen Scrum Master und ggf. einen Product Owner (sofern diese Rolle nicht durch den Moderator eingenommen wird), die für das Beseitigen von Hindernissen und das Beschaffen von Informationen zuständig sind. Die einzelnen Rollen in Scrum müssen den Teams nicht bekannt sein. Die Aufgaben von Team, Scrum Master und Product Owner müssen dann allerdings vorm Start der Umsetzung beschrieben werden.

Die Aufgabe

Die Aufgaben, die die Teams erhalten, enthalten zum Teil nicht alle Informationen oder können mit den zur Verfügung gestellten Duplo-Bausteinen nicht gelöst werden. Der Moderator beobachtet das Verhalten der Teams während der Umsetzung und diskutiert anschließend die Herangehensweise zur Umsetzung der jeweiligen Aufgaben. Dabei soll zum einen vermittelt werden, dass die Kommunikation im Team wichtig ist, um eine Aufgabe gemeinsam zu lösen. Zum anderen soll diese Form des spielerischen Erlebens von Scrum dazu beitragen, dass die Beteiligten verstehen, dass nur klare Absprachen und die Kommunikation über Abteilungsgrenzen hinweg zum Ziel führen.

Spieldauer

Die Spieldauer sollte abhängig von den gestellten Aufgaben, der Firmenkultur (ist „spielen“ gern gesehen?) und der Teilnehmermenge gewählt werden. Eine mögliche Zeiteinteilung ist:

  • 15 Minuten Erklärungen zu Scrum im Unternehmen zum Ablauf und zu den Rollen
  • 20 Minuten Spiel-Durchführung
  • 10 Minuten Diskussion um Sinn und Zweck des Spiels oder zur Retrospektive

Aufgabenbeispiel

Eine mögliche Aufgabe ist das Bauen einer Garage. Je nachdem, welches Ziel mit der Aufgabe verfolgt wird, können beliebig viele Informationen fehlen, um die Teilnehmer auf eine falsche Fährte zu führen. So kann zum Beispiel eine Garage für das Unterstellen des Sportflugzeuges gewünscht sein. Die Teilnehmer werden beim Wort Garage sicherlich an eine Garage für Autos denken und diesen Punkt erst gar nicht nachragen…



Die Bausteine können z.B. im Lego Shop Deutschland erworben werden.

Aufwandsschätzung mit Story Points

Verwendung von Story Points zur Aufwandsschätzung

In der agilen Softwareentwicklung werden oftmals sog. Story Points eingesetzt, um eine Aufwandsschätzung durchzuführen. Dabei wird zumeist nicht der Aufwand in Personentage zum Erledigen geschätzt, sondern die Komplexität einer Aufgabe. Die Definition der Komplexität wird dabei vom Team erarbeitet und definiert.

In der Regel sind hohe Schätzwerte ein Indiz dafür, dass die aktuellen Informationen nicht ausreichen, um eine konkrete Schätzung abgeben zu können. Ggf. muss in einem solchen Fall der Product Owner mehr Informationen und Anforderungen liefern oder das Team muss die Story in besser schätzbare Teile auseinander brechen.

Erstellen eines Wertebereiches

Als Wertebereich wird zumeist die Fibonacci-Reihenfolge bis 13, ergänzt mit 20, 40 und 100, verwendet. Zur Verdeutlichung der Bedeutung eines Wertes, kann eine Wertetabelle erstellt werden. Ein Beispiel stellt die folgende Tabelle dar:

Wert Bedeutung Beschreibung
0 Bereits erledigt
1 Sehr klein Aufgabe mit niedriger Komplexität
2 Klein Doppelt so große Komplexität wie eine sehr kleine Aufgabe
3 Mittel Entspricht einer sehr kleinen und kleinen Aufgabe
5 Mittelgroß Komplexität entspricht bereits einer mittleren Aufgabe und einer kleinen Aufgabe
8 Groß Komplexität entspricht einer mittelgroßen und einer mittleren Aufgabe
13 Sehr groß Komplexität entspricht einer großen und einer mittelgroßen Aufgabe
20 Riesig Ca. so groß wie eine große und eine sehr große Aufgabe zusammen
40 Gigantisch Kaum schätzbar, doch mindestens so groß wie zwei riesige Aufgaben
100 Unendlich Nicht schätzbar mit aktuellem Wissenstand Unfassbar!

Der Vorteil von Story Points

Die Verwendung von Story Points hat den Vorteil, dass anhand einer Schätzung nicht auf Anhieb der Aufwand abgeleitet werden kann. Schätzungen sind somit weiterhin das, was sie sind: eine vage Ausgabe über die Komplexität, basierend auf einer Schätzung. Ein weiterer Vorteil ist, dass Schätzungen basierend auf Story Points nicht verwendet werden können, um die Performance von Team-Mitgliedern oder Teams miteinander vergleichen zu können. Jedes Team erstellt für sich selbst eine eigene Wertetabelle der Schätzpunkte und findet ein für sich passendes System, um Aufgaben zu schätzen. Daher sind Abweichungen innerhalb eines Unternehmens bisweilen unausweichlich.

Erstellen eines Wertebereichs anhand eines Beispiels

story-points-Wertetabelle-270x250@2x
Wertetabelle

Eine Methode zum Definieren einer Wertetabelle ist das Heranziehen einer Referenz-Story. Dabei einigt sich das Team zunächst auf eine Referenz-Story, die nicht zu groß und nicht zu klein ist und die von allen Team-Mitgliedern geschätzt werden kann. Aufbauend auf dieser Referenz, werden die weiteren Stories im Backlog geschätzt und in eine Relation zueinander gesetzt. Aufgaben mit vergleichbaren Schätzungen können gestapelt werden, so dass im Idealfall am Ende eine überschaubare Anzahl Stapel übrig bleibt. Eine Lösung zum Aufbau der Wertetabelle kann sein, dass der Stapel mit der niedrigsten Schätzung die Story Point-Wertung 1 erhält, der nächste Stapel die 2 usw.

Schätzung der Dauer anhand der Velocity

Um aus geschätzten Stories ableiten zu können, wie lange es in etwa dauern wird, bis sie umgesetzt worden sind, wird die Velocity herangezogen. Die Velocity ist der Durchsatz an Story Points, den das Team bisher erzielt hat (bzw. die Anzahl der Story Points, die das Team pro Sprint erledigt). Über mehrere Sprints hinweg wird festgehalten, wie viele Story Points erledigt werden konnten. Bleiben Wertetabelle, Referenz-Stories und Team-Zusammensetzung über diesen Zeitraum gleich, kann diese Velocity zur Release-Planung verwendet werden. Ein eingespieltes Team wird im Laufe eines Projektes die Velocity vermutlich steigern und folglich mehr Story Points pro Sprints als am Anfang umsetzen können. Die Schätzungen der Stories sind davon nicht betroffen und müssen nicht angepasst werden, da sie lediglich etwas über die Komplexität, aber nicht den Aufwand aussagen.