Scrum Masters auch dazu gedacht, in die Organisation hineinzuwirken. Wenn man mit Scrum beginnt, wird man schnell feststellen, dass gewisse Hindernisse, die eine selbstorganisierte Arbeit verhindern, nicht nur innerhalb der Teamgrenzen zu finden sind. Viele Probleme und Herausforderungen sind teamübergreifend und zum Beispiel in vorhandenen Strukturen oder Prozessen begründet. Es ist unvermeidlich, dass ein Unternehmen, das sich agil aufstellen möchte und dafür Scrum einführt, sich auch organisatorisch deutlich verändern muss.
Exkurs | Rollen und Positionen
Scrum definiert drei Rollen. In vielen klassischen Organisationen besteht eine sehr starke Fokussierung auf Positionen. Auch wenn beide Begriffe oft synonym verwendet werden, besteht hier ein deutlicher Unterschied. Eine Position ist untrennbar mit einer Person verknüpft. Frau Maier oder Herr Müller haben eine Position inne. An diese Position wiederum sind gewisse Rechte und Pflichten geknüpft. Ein Projektleiter trägt die Verantwortung für ein bestimmtes Projekt und hat vielleicht ein Budget zur Verfügung und dann auch eine Weisungsbefugnis für die Projektbeteiligten. Positionen sind in der Regel ein Kästchen in einem Organigramm, in dem ein bestimmter Name steht.
Rollen hingegen definieren erst einmal nur Verantwortlichkeiten, sind aber nicht personenbezogen. Das heißt, die in einer Rolle definierten Verantwortlichkeiten müssen erfüllt werden, aber es ist nicht unbedingt festgelegt, welche Person dies tut. Somit kann eine Rolle auch durch mehr als eine Person ausgefüllt werden, indem man beispielsweise die Verantwortlichkeiten aufteilt.
In sehr vielen Unternehmen wird eine Rolle an eine Position geknüpft. In manchen Fällen ist der Product Owner, der in Scrum als Rolle definiert ist, eine feste Position mit einer zugeordneten Person. Andernorts sind an die Position (das Kästchen im Organigramm) noch zusätzliche (nicht im Scrumguide definierte) Aufgaben, Rechte oder Pflichten geknüpft. Hier findet schnell eine Vermischung von Rolle und Position statt, die am Ende zu einem falschen Verständnis von den eigentlichen Rollen führen kann.
Neben diesen Rollen gibt Scrum auch ziemlich genau vor, welche Bestandteile es gibt und zu welchen Anlässen und wann die Teams zusammenkommen (Scrum Artefakte und Events).
Das Product BacklogProduct Backlog haben Sie ja schon kennengelernt. Es handelt sich dabei um eine Liste, die alle Arbeit enthält, die vom Team zu erledigen ist, um ein Produkt herzustellen. Diese Liste ist geordnet und die wichtigste Aufgabe befindet sich an der Spitze dieser Liste. Der Product Owner ist dafür verantwortlich, das Product Backlog aktuell zu halten und die Reihenfolge der Arbeit festzulegen. Die einzelnen Bestandteile des Backlogs nennt man Product Backlog Items. Diese werden oftmals in Form einer User Story (also aus der Sicht des Benutzers) geschrieben. Product Backlog Item ist alles, was eine Änderung am bestehenden Produkt darstellt, also zum Beispiel neue Anforderungen, Fehlerbehebungen oder die Beseitigung technischer Schulden.
Die Abarbeitung der Product Backlog Items erfolgt in Iterationen, sogenannten SprintsSprint. Ein Sprint ist per Definition maximal vier Wochen lang. Da die Vorausplanung mit zunehmender Länge der Iteration immer ungenauer wird, legt der Scrumguide hier diese Obergrenze fest. Für die meisten Teams hat sich eine Sprintdauer von zwei Wochen in der Praxis als guter Startwert herausgestellt. Es gibt aber auch Scrum Teams, deren Sprints nur einen Tag dauern, oder die sogar mehrere Sprints an ein und demselben Tag durchführen.
In einem gemeinsam Scrum Event (so nennt man bei Scrum die gemeinsamen Termine in Abgrenzung zu den gemeinhin oftmals als unproduktiv angesehenen „Meetings“), dem sogenannten Sprint PlanningSprint Planning, setzt sich das gesamte Scrum Team (Product Owner, Scrum MasterScrum Master und Entwicklungsteam) zusammen und überlegt, was es im nächsten Sprint voraussichtlich liefern kann. Dafür wird erst einmal ein Sprintziel festgelegt und dann Aufgaben aus dem Product Backlog ausgewählt, die zur Erreichung des Ziels notwendig sind.
Diese Aufgaben werden dann in das Sprint BacklogSprint Backlog übertragen. Dieses stellt somit eine Teilmenge des Product Backlogs dar und wird jeden Sprint neu angelegt. Die Aufgaben im Sprint Backlog werden so verfeinert, dass das Team jederzeit überprüfen kann, wie sein Fortschritt in Hinblick auf die Erreichung des Sprintziels ist. Es werden nur so viele Aufgaben in das Sprint Backlog übernommen, wie das Team meint, im nächsten Sprint fertigstellen zu können.
Im Laufe des Sprints erstellt das Entwicklungsteam ein Inkrement. Ein Inkrement besteht aus dem Ergebnis des aktuellen Sprints sowie den Ergebnissen aller vorheriger Sprints. Ein Produkt Inkrement wird also von Sprint zu Sprint immer größer und umfangreicher.
Damit die Arbeit selbstorganisiert stattfindet und möglichst gut abgestimmt wird, trifft sich das Entwicklungsteam täglich zur selben Zeit am gleichen Ort für ein Planungs- und Abstimmungsmeeting, dem Daily Scrum. Das Daily Scrum findet in aller Regel im Stehen statt (daher auch der alternative Name Daily-Stand-Up). Dies soll dazu dienen, dass die Teilnehmer sich kurzfassen und schnell zum Wesentlichen kommen. Alle Scrum Events haben eine Timebox (Zeitrahmen), also eine maximale Dauer, die nicht überschritten werden darf. Das Daily Scrum soll maximal 15 Minuten dauern und ist somit das kürzeste Scrum Event. Hervorzuheben ist, dass das Daily Scrum nicht dazu gedacht ist, den aktuellen Status zu berichten. Das Team soll sich gezielt abstimmen, wo man im Hinblick auf das Sprint Ziel steht, was noch zu tun ist, was in den nächsten 24 Stunden (bis zum nächsten Daily Scrum) erledigt werden kann und wie man sich am sinnvollsten aufteilt. Zudem sollen Hindernisse (Impediments) sichtbar gemacht werden, die die Arbeit behindern oder sogar verhindern.
Damit eine Aufgabe vom Team als erledigt gekennzeichnet werden kann, muss sie der Definition von Fertig (Definition of Done) entsprechen. Diese Definition stellt eine Checkliste dar, die alles enthält, was erfüllt sein muss, damit eine Aufgabe fertiggestellt ist. Diese wird häufig von dem Unternehmen vorgegeben, damit alle Scrum Teams nach den gleichen Qualitätsstandards arbeiten. Wenn auch nur eine geringe Kleinigkeit fehlt, darf eine Aufgabe nicht als fertig deklariert werden.
Am Ende des Sprints präsentiert das Scrum Team allen Interessierten das fertige Inkrement (also alle Aufgaben, die gemäß der Definition von fertig abgeschlossen wurden). Dies geschieht im sogenannten Sprint Review, das eine öffentliche Veranstaltung ist und zu dem der Product Owner alle interessierten Stakeholder einlädt. Gemäß dem Leitsatz von Scrum – Inspect & Adapt (Feedback einholen und Anpassen) – wird hier das Produkt Inkrement gezeigt und Feedback eingesammelt. Auch das Review ist somit kein einfaches Statusmeeting, um einen Fortschritt zu präsentieren, sondern eine wichtige Gelegenheit, um Feedback einzuholen und strategische Entscheidungen zu treffen. Neue Erkenntnisse hält der Product Owner im Backlog fest, mit dem er dann in das nächste Sprint Planning gehen kann.
Im Anschluss erfolgt dann ein weiterer Schritt, der dazu dient, Feedback einzuholen und eventuelle Anpassungen vorzunehmen: die Sprint Retrospektive. Hier kommt das Scrum Team zusammen und reflektiert gemeinsam den Entwicklungsprozess mit dem Ziel, Verbesserungsmaßnahmen zu definieren, die im Laufe des nächsten Sprints angewendet und in der folgenden Retrospektive auf ihre Wirksamkeit hin untersucht werden können. Diese werden dann auch gleich in das Sprint Backlog des nächsten Sprints eingetragen, damit das Team bei der Planung diese Aufwände mitberücksichtigen kann.
Prinzipiell geht der Zyklus an dieser Stelle wieder von vorne los, allerdings zeigt die Erfahrung, dass das Team auch eine gewisse Zeit in die Pflege und die Verfeinerung des Product Backlogs investieren muss. Diese Aktivität wird als Refinement bezeichnet. Der Scrumguide macht hier, im Gegensatz zu den klar definierten Scrum Events, keine klaren Vorgaben, wie das Refinement abzulaufen hat. Aber er gibt eine Empfehlung, die darin besteht, dass das Team bis zu 10 % seiner Zeit im Sprint für Refinement aufwenden sollte. Das Ergebnis – ein gepflegtes und feingranulares Product Backlog – wird dann als Eingabe für das nächste Sprintplanning genutzt.
Auch in Scrum gibt es Metriken, die helfen sollen, den Prozess kontinuierlich zu verbessern. Allerdings schreibt Scrum hier nichts vor. Viele Praktiker messen zum Beispiel gerne die Menge der Arbeit, die das Entwicklungsteam in einem Sprint erledigt hat. Dies wird dann als Velocity bezeichnet. Dafür muss die Größe der Aufgaben berücksichtigt werden, so dass man entweder alle