Dennis Willkomm - Roadmap durch die VUCA-Welt

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 Sprintist 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 Scrumfindet 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 Refinementbezeichnet. 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 Velocitybezeichnet. Dafür muss die Größe der Aufgaben berücksichtigt werden, so dass man entweder alle Aufgaben in die gleiche Größe bringt oder aber die Größe schätzen und in Relation zueinander setzen muss. Hierfür werden meist Story Points verwendet. Dementsprechend wird auch die Velocity eines Teams in der Regel in Story Points pro Sprint angegeben.

Scrum und Kanban erheben beide nicht den Anspruch perfekt zu sein und die Antwort auf alle Fragen zu liefern. Im Gegenteil, sie ermutigen die Anwender dazu, Anpassungen vorzunehmen, um die Vorgehensweisen zu verbessern. Dies ist sicherlich eine gute Idee, denn die Erfinder konnten nicht jeden erdenklichen Kontext in ihre Überlegungen einbeziehen.

Ich erinnere mich noch recht gut an einen Lieblingsfilm meiner Kindheit. Ein schmächtiger, schwarzhaariger Junge steht vor einem Auto. Ihm gegenüber steht ein kleiner Japaner mit einem Schwamm in der Hand. „Auftragen rechte Hand, polieren linke Hand“, leitet der kleine Japaner ihn an. Dabei solle er das Atmen nicht vergessen, ergänzt der wunderliche alte Mann, dann macht er die Bewegung noch einmal vor. Er übergibt dem sparsam dreinschauenden Jungen den Schwamm und überlässt ihn dann seiner Aufgabe. Der Junge ist verdutzt, will er doch eigentlich Karate lernen und sein Lehrer, Mr. Miyagi, lässt ihn nun mit einer Aufgabe stehen, deren Sinn er nicht versteht. Diese Szene aus dem Film „Karate Kid“ ist ein schönes Beispiel für ein Prinzip namens Shu-Ha-RiShu-Ha-Ri. Dieses Konzept aus der Kunst des fernöstlichen Kampfsportsist auch bei der Einführung und Umsetzung von Arbeitsweisen und Methoden hilfreich.