Dialog zu Scrum

9. September 2014
Liefern, was gebraucht wirdNo Comments

Scrum

Scrum ist ein agiles Projektmanagement-Framework, das um die Jahrtausendwende von Ken Schwaber und Jeff Sutherland vor dem Hintergrund der Software-Krise erdacht und seitdem kontinuierlich weiterentwickelt worden ist.

Fliegengewicht mit 17 Seiten Dokumentationsumfang

Scrum ist ein leichtgewichtiges Framework und grenzt sich damit von umfangreichen Projektmanagement-Regelwerken ab. Der Scrum Guide, die offizielle Definition von Scrum, umfasst gerade einmal 17 Seiten. Scrum nutzt ein iterativ-inkrementelles Vorgehen, um am Ende einer jeden Iteration (Sprint genannt) ein fertiges Teilprodukt ausliefern zu können. Diese Sprints sind alle gleich lang (zwischen wenigen Tagen und vier Wochen) und schließen nahtlos aneinander an. Dadurch entsteht ein Takt, in den das Projektteam einschwingt und der einem Scrum-Projekt eine verlässliche Struktur gibt. Scrum besteht im Kern aus drei Rollen, vier Meetings, drei Artefakten sowie der Definition of Done, die im Scrum Guide beschrieben sind:

Rollen

Product Owner
  • ist verantwortlich für das „Was“, d.h. für die inhaltliche Gestaltung des Produkts, sowie für die Finanzierung der Produktentwicklung
  • kommuniziert mit Kunden und anderen Interessenvertretern
  • ist verantwortlich für das Product Backlog und dessen kontinuierliche Pflege
  • sorgt dafür, dass das Entwicklungsteam die User Stories aus dem Product Backlog soweit versteht, dass es deren Komplexität abschätzen und die Stories in ein nutzbares (Teil-)Produkt überführen kann
  • nimmt die Sprint-Ergebnisse ab
Entwicklungsteam
  • ist verantwortlich für das „Wie“, d.h. für die handwerklich solide Softwareentwicklung unter Nutzung geeigneter und zukunftssicherer Technologien und bürgt für eine hohe Qualität des am Sprint-Ende gelieferten Teilprodukts
  • besteht aus drei bis neun Personen und ist idealerweise über die gesamte Projektlaufzeit personell stabil
  • vereint alles Wissen, alle Fähigkeiten und Fertigkeiten, die notwendig sind, um das Produkt gemäß der „Definition of Done“ zu erstellen (cross-funktionales Team)
  • arbeitet selbstorganisiert und selbstbestimmt; legt beispielsweise eigenverantwortlich fest, wie viele User Stories in einen Sprint aufgenommen werden
Scrum Master
  • ist verantwortlich dafür, dass Scrum von allen Projektbeteiligten ver-standen und zum Zwecke der Zieler-reichung eingesetzt wird
  • ist ein dienender Führer für die an-deren Scrum-Rollen und methodi-scher Vermittler für alle Personen aus dem Projektumfeld
  • ist Moderator, Coach, Innovator, So-zialarbeiter, Schiedsrichter und Evangelist

Die Rollenbeschreibungen deuten es an: Scrum ist zwar leichtgewichtig, aber keinesfalls leicht in der Anwendung. Es bedarf eines gut ausgebildeten und vor allem lernwilligen Teams, um Scrum erfolgreich einzusetzen. Dank der klaren, überschneidungsfreien Aufteilung der Verantwortlichkeiten auf die drei Rollen kann Scrum die Zusammenarbeit in einem solchen Team bestmöglich unterstützen.

Meetings

Ein weiterer Baustein für die erfolgreiche Zusammenarbeit sind die regelmäßigen Meetings, die einen kontinuierlichen Dialog auf der inhaltlichen und der Prozessebene gewährleisten.

Meeting Agenda
Sprint Planning
Zu Beginn eines Sprint
  • Welche User Stories aus dem Product Backlog werden Bestandteil des Produktinkrements, das am Ende des Sprint geliefert wird?
  • Was ist zu tun, um das Produktinkrement liefern zu können?
Daily Scrum
Täglich, max. 15 min.
  • Was habe ich gestern getan, um das Entwicklungsteam bei der Erreichung des Sprint-Ziels zu unterstützen?
  • Was werde ich heute tun, um das Entwicklungsteam bei der Erreichung des Sprint-Ziels zu unterstützen?
  • Welche Hindernisse sehe ich, die das Entwicklungsteam von der Erreichung des Sprint-Ziels abhalten?
Sprint Review
Am Ende eines Sprint
  • Welche User Stories wurden gemäß der „Definition of Done“ fertiggestellt, welche nicht?
  • Live-Präsentation der fertiggestellten User Stories durch das Entwicklungsteam
  • Beantwortung offener Fragen, Sammeln neuer Ideen für das Product Backlog
  • Vorschau auf den nächsten Sprint und das nächste Release
Sprint-Retrospektive
Am Ende eines Sprint
  • Bewertung des vergangenen Sprint hinsichtlich der Individuen im Team, deren Beziehungen, des Prozesses und der verwendeten Werkzeuge
  • Sammeln von Erfolgsfaktoren und Verbesserungspotenzialen
  • Definieren und Priorisieren von Maßnahmen zur Prozessverbesserung; welche dieser Maßnahmen sollen im kommenden Sprint umgesetzt werden?

Das Agile Manifest bewertet funktionierende Software höher als umfassende Dokumentation. Deshalb beschränkt sich der Scrum Guide auf die minimal notwendige Dokumentation. Das bedeutet natürlich nicht, dass in Scrum-Projekten nicht zusätzliche Dokumentation geliefert werden darf. Insbesondere in regulierten Domänen ist dies gesetzlich vorgeschrieben. Allerdings sollten auch in diesen Bereichen immer die drei Mu-Prinzipien aus dem Toyota-System berücksichtigt werden.

Artefakte

Product Backlog Das Product Backlog ist eine geordnete Liste der Anforderungen an das Produkt, meist beschrieben in Form von User Stories. Diese Anforderungen sind

  • nach verschiedenen, definierten Kriterien geordnet, beispielsweise Geschäftswert, Risiko und Abhängigkeiten zwischen User Stories.
  • umso detaillierter beschrieben, je größer die Wahrscheinlichkeit ist, dass sie in einem der kommenden Sprints umgesetzt werden sollen; große Themenbereiche, die bisher nur grob skizziert wurden, ohne die darin verborgenen User Stories zu beschreiben, werden als Epics bezeichnet.
  • vom Entwicklungsteam bezüglich ihrer Komplexität abgeschätzt.
  • veränderlich: sie können sich inhaltlich ändern, in kleinere User Stories aufgeteilt, gelöscht oder um neue User Stories ergänzt werden.
Sprint Backlog Die Liste der User Stories, die für den Sprint ausgewählt wurden, ergänzt um die Tätigkeiten (Tasks), die notwendig sind, um diese User Stories zu implementieren.
Inkrement Der Produktumfang, der durch die Fertigstellung der User Stories im letzten Sprint erweitert wurde. Hier werden nur jene User Stories gezählt, die gemäß der „Definition of Done“ fertiggestellt worden sind.
Definition of Done Eine genaue Beschreibung aller Kriterien, die erfüllt sein müssen, damit eine User Story als fertiggestellt betrachtet werden kann. Diese Definition wird vom gesamten Scrum-Team gemeinsam erstellt und kann im Laufe des Projekts überarbeitet werden.

Auf der Basis des Scrum-Frameworks lässt sich ein einfaches, tagesgenaues Controlling installieren, das im Wesentlichen den Abarbeitungsstand der User Stories und der Tasks erfasst. Abweichungen vom prognostizierten Sprint-Verlauf können frühzeitig erkannt und behandelt werden. Die Auswirkungen auf eine übergeordnete Release-Planung werden ebenfalls frühzeitig sichtbar.

Weiterführende Informationen

  • www.scrumalliance.org – die Gralshüter von Scrum
  • www.scrum.org – Scrum-Erfinder Jeff Sutherland gründete aus Unzufriedenheit mit dem Stand der Dinge in Sachen Scrum 2009 diese Organisation