Auf den ersten Blick fällt auf, dass die Sprache und viele Begriffe sich verändert haben. Der neue Scrum Guide versucht, die Sprache zu vereinfachen und die früher starken Bezüge zur IT-Industrie abzuschwächen. Der Guide wird generischer und trägt damit Entwicklungen in der Praxis Rechnung.
Auffällig ist auch, dass der Guide schlanker wurde, eine Reihe von Detailregeln und Anweisungen sind weggefallen, der Guide beschränkt sich auf die Beschreibung des Frameworks. Das bedeutet nicht, dass die Details aus der Vorgängerversion (2017) keinen Sinn mehr machen. Wenn Sie zum Beispiel die drei Leitfragen zur Struktur des Daily Scrums hilfreich finden, dann verwenden Sie sie weiter. Der Scrum Guide geht nur nicht mehr auf diese Detailebene und will weniger vorschreibend sein.
Einige Änderungen möchte ich hervorheben, da sie einen deutlichen Unterschied machen. Da ist zu allererst die Sicht auf das Scrum Team.
Das neue Scrum Team
Im neuen Scrum Guide gibt es nur noch ein Team, das Scrum Team. Die Developers werden nicht mehr als Team im Team bezeichnet. Das hat offenbar zu Verwirrungen geführt. Nun ist es ein Team, das Sprint für Sprint in seiner Gesamtheit die Umsetzungsverantwortung (responsibility) für alle seine Aktivitäten und die Ergebisverantwortung (accountabbility) für nützliche und wertvolle Increments trägt.
Innerhalb des Scrum Teams bleiben die unterschiedlichen Verantwortlichkeiten von Product Owner, Developern und Scrum Master bestehen. Sie werden jedoch nicht mehr Rollen genannt, sondern Ergebnisverantwortlichkeiten (accountabilities).
Product Goal, Sprint Goal und Definition of Done
Bekannt ist das Sprint Goal, also das Ziel, das in einem Sprint erreicht werden soll: Das, worauf die Bearbeitung der einzelnen Items hinauslaufen soll, also das „Warum“. Das Sprint Goal soll nun im Sprint Backlog festgehalten werden und stets für alle sichtbar sein.
Dasselbe gibt es jetzt auch für das Product Backlog, das Product Goal. Das ist eine Beschereibung des Warums des Produktes, denn das Produkt ist ja nur das Instrument, um einen Wert zu schaffen. Damit soll die Orientierung der Backlog Items klarer werden, weil es im Broduct Backlog fixiert und transparent ist.
Als drittes „Committment“ ist die Definition of Done ja grundsätzlich bereits bekannt. Das ist die eindeutige Beschreibung des Zustands der Increments, der sie akzeptabelmacht: Damit ist sie der eindeutige Orientierungspunkt und Qualitätskriterium für die einzelnen Increments. Die Definition of Done gehört eindeutig zu den Increments.
Spint Planning
Wie im oberen Abschnitt beschrieben, wird die Betonung des „Warum“ deutlich wichtiger und ernster genommen. Auch in Scrum kann man Items perspektivlos abarbeiten. Dem soll ein Riegel vorgeschoben werden, gerade weil sich viele Teams schwer tun, ein Sprint Goal zu definieren.
Das Sprint Planning besteht nun aus drei Themen:
- Warum ist dieser Sprint wertvoll? Hier geht es um den Wert, um den das Produkt wachsen soll und um das Sprint-Ziel.
- Was kann in diesem Sprint abgeschlossen werden? Nun geht es um die Auswahl der Items und die Erstellung des Sprint-Backlos
- Wie wird die ausgewählte Arbeit erledigt? Jetzt wird die ausgwählte Arbeit geplant, um die Inkremente zu erstellen, die der Definition of Done entsprechen. Dieser Plan macht das Sprint-Backlog vollständig.
Alles in Allem einige sehr anregende Änderungen, die auf Herausforderungen der Praxis reagieren. Die konkrete Anwendung in der betrieblichen Praxis wird zeigen, wie sie sich bewähren.