Scrum-Guide 2020: One Team, one Product

An English version of the article is available on Medium.

Mit großen Worten wurde der Scrum-Guide angekündigt und heute wurde er dann endlich veröffentlicht. Im heutigen Artikel gebe ich euch einen kommentierten Überblick der Änderungen.

Die Änderungen am Scrum-Guide sind dieses Mal besonders groß ausgefallen, wobei ein Großteil der Änderungen vor allem der besseren Lesbarkeit und Verständlichkeit dient. Eine im Grunde bemerkenswerte Demonstration der Scrum-Lehre, dass ein Produkt zwar potenziell auslieferungsfähig sein soll, aber nicht unbedingt auch ausgeliefert werden muss 😉

Darüber hinaus gibt es aber auch zwei größere Änderungen, die sich in Änderungen an beinahe allen Teilen des Scrum-Guides niedergeschlagen haben.

Ein Team und ein Produkt

One Team, Focused on One Product.

Revisionshistorie des Scrum-Guide, 2020

Ein Team und ein Produkt könnte wohl als das übergeordnete Motto des neuen Scrum-Guides bezeichnet werden.

Das Team hatte in Scrum schon immer einen hohen Stellenwert, aber mit dem neuen Scrum-Guide gibt es keine Unterscheidung zwischen Scrum-Team und Entwicklungsteam mehr. Hinzugekommen ist dagegen ein Produktziel.

Das Produktziel soll den zukünftigen Zustand des Produkts in einer Art und Weise beschreiben, die dem Team bei der Planung der Sprints hilft. Der Scrum-Guide beschreibt es als die langfristige Zielsetzung für das Produktteam. Das Produktziel zu definieren, weiterzuentwickeln und verständlich zu kommunizieren, ist (wenig überraschend) die Aufgabe des Product Owners. Aber im bisherigen Geiste des Scrum-Guides und vor dem One-Team-Gedanken ist es sicherlich auch weiterhin erlaubt, dass der Product Owner hier auch das restliche Team mit einbezieht. Damit wir Ziele auch tatsächlich erreichen, ist es bekanntermaßen von Vorteil, wenn wir sie uns selbst gesetzt haben.

Das Scrum-Team – weiterhin bestehend aus Product Owner, Entwicklern und Scrum Master – soll dem Guide zufolge gemeinsam auf dieses Ziel hinarbeiten. Als Team sollen sie gemeinsam entscheiden was, wann und wie getan ist. Das Scrum-Team ist demnach für alle anfallenden Aufgaben gemeinsam zuständig. Beispielhaft erwähnt wird die Kommunikation mit Stakeholdern, die Durchführung von Experimente, Wartungstätigkeiten und so weiter.

Vermeiden dysfunktionaler Teammuster

Die Änderung soll helfen „Wir gegen sie“ Situationen zu vermeiden sowie Situationen, in denen der Product Owner zum Bottleneck wird.

Beispielsweise wissen viele von uns, dass es ungünstig sein kann, wenn der Product Owner als abschirmender „Proxy“ zwischen Stakeholdern den Entwicklern dient. Die ein oder andere anekdotische Erzählung hat es uns verraten oder aber eigene schmerzliche Erfahrung. Sind die Entwickler zu weit weg vom Kunden, führt das nicht nur dazu, dass der Product Owner zum Bottleneck wird, sondern bringt auch das Risiko für ein fehlendes Verständnis für Kundenbedürfnisse.

Der Scrum-Guide will diesem Problem nun mit dem One-Team-Ansatz begegnen und entsprechend wirkt sich das auf diverse Stellen im Scrum-Guide aus. Beispielsweise haben sich Änderungen an den beschriebenen Aufgaben oder besser gesagt Rechenschaftspflichten ergeben.

Im Detail werde ich hierauf an dieser Stelle nicht eingehen, denn das lässt sich im Scrum-Guide selbst doch sehr gut nachlesen.

Empirismus ist immer noch wichtig

Klar ist: Scrum basiert auf der der Idee der Empirie.

Das ist nicht neu, aber im neuen Scrum-Guide gehen die Autoren die Extrameile, um das wirklich, wirklich deutlich zu machen. Wirklich.

Das beginnt schon mit der Definition of Scrum, in der nun hervorgehoben wird, zu welcher Art von Umgebung die Arbeit des Scrum Masters beitragen sollte.

Nämlich eine Umgebung, in der Product Owner und Scrum Team sich auf das Wesentliche konzentrieren können:

1. Die Pflege des Product Backlogs durch den Product Owner
2. Die Arbeit am Produkt
3. Die Begutachtung des Produkts zusammen mit den Stakeholdern
4. Wiederholung der Prozedur

Darüber hinaus enthält der Scrum-Guide nun den Hinweis, dass Lean Thinking Einfluss auf Scrum genommen hat.

Der ehemalige Spruch, dass Scrum „lightweight, simple to understand and difficult to master“ sei ist entfallen. Gut so, denn vor dem Hintergrund der vielen kursierenden Verständnisprobleme schien dieser Teil immer etwas fehlplatziert.

Dann sind wir im Hinblick auf die Grundlagen noch folgende Dinge aufgefallen:

• Die Wichtigkeit von Rhythmus: Der Guide stellt nun klar, dass die Events zu einem Rhythmus für die Inspection beitragen sollen.
• Die Wichtigkeit von Empowerment: Ein Hinweis wurde eingefügt, dass die Anpassung an Erkenntnisse schwer fällt, wenn das Team nicht über genügend Entscheidungsbefugnisse verfügt.
• Der beste Zeitpunkt für Anpassung: Der Zeitpunkt, wann auf Erkenntnisse reagiert werden soll, wurde ebenfalls klar gestellt: nicht nur so früh wie möglich sondern möglichst sobald man es bemerkt.

Gerade der letzte Punkte ist sehr im Einklang mit den heutigen DevOps-Praktiken und zeigt die Einflüsse von Lean Thinking. Schon im Toyota-System gab es ja das Konzept der „Andon-Cord“, die beim Auftreten von Fehlern gezogen werden und dazu führen soll, dass sich alle auf die Problembehebung konzentrieren.

Änderungen bei den Events

Bei den Events wurde vor allem um all zu bevormundenden Äußerungen gekürzt und die Verständlichkeit verbessert. Sonst hat sich vor allem für das Planning eine Änderung ergeben, aber es gibt auch ein paar kleine nette Details.

Der Sprint

Sprints are the heartbeat of Scrum, where ideas are turned into value.

Scrum-Guide 2020

Der Herzschlag von Scrum wird der Sprint im Scrum-Guide nun genannt. Damit soll wohl nochmal darauf hingewiesen werden, dass es um Rhythmus und nicht um Geschwindigkeit steht.

Zu einer Änderungen der Bezeichnung haben sich die Macher nicht durchgerungen, ein entsprechendes Gesuch war erst kürzlich wieder abgelehnt worden.

Interessant ist, dass der Scrum Guide Stellung zu verschiedenen ergänzenden Praktiken nimmt, wie Burn Down-Charts oder Cumulative Flow Diagrammen. Ganz nützlich in der Praxis, ja, aber keinesfalls wichtiger als Empirismus. Noch einmal deutlich sagt der Scrum-Guide, dass für Entscheidungen nur auf das zurückgegriffen werden kann, was schon passiert ist.

Das Planning

Im Planning ist die wesentlichste Änderung, dass die Frage nach dem „Why?“ als eigenständiger Schritt betrachtet wird. Als Ergebnis dieses Schritts soll das Sprint-Goal definiert werden. Dieses soll am Ende der Sprint-Planung in jedem Fall stehen.

Überdies stellt der Scrum-Guide jetzt klar, dass der Product Owner sicherstellen soll, dass die Teilnehmer auf das Event vorbereitet sind. Also, dass sie im Planning die wichtigsten Anforderungen und wie sie zum Produktziel beitragen besprechen können.

Das Daily Scrum

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

Das Ziel des Daily Scrum – Fortschritt auf das Sprintziel begutachten und die Arbeit für den Tag zu planen – hat sich nicht geändert.

Der Scrum-Guide setzt allerdings klar den Fokus darauf, den Sinn des Daily-Scrum zu beschreiben statt Vorgaben zu dessen Durchführung zu machen. Und ja – den Einschnitten fallen auch (und endlich) die häufig diskutierten drei Fragen zum Opfer, die das Daily häufig zu einem Status Report verkommen ließen.

Fraglich nur, ob man die jemals wieder aus den Köpfen der Menschen raus bekommt.

Das Sprint-Review

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations

Die Essenz des Sprint-Reviews ist und bleibt das Produkt und dessen Fortschritt auf das Produktziel zu begutachten. Gut, das Produktziel ist an dieser Stelle natürlich neu.

Ansonsten hält sich der Scrum-Guide nun ebenfalls erfreulich vage und sagt im Wesentlichen: in diesem Event geht es um Zusammenarbeit, das Product-Backlog kann dabei angepasst werden kann und eine reine Präsentation sollte vermieden werden.

Die Sprint-Retrospektive

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

Logisch.

In der Retro geht es um Verbesserung der Zusammenarbeit. Der Scrum-Guide wird an dieser Stelle sogar etwas konkreter. In der Retro soll untersucht werden wie der letzte Sprint in Hinblick auf die Individuen, Interaktionen, Prozesse, Tools und die Definition of Done gelaufen ist. Auch legt der Guide nah, Annahmen zu hinterfragen, die sich als falsch erwiesen haben.

Am Ende sollen Veränderungen ermittelt werden, mit denen sich die Effektivität des Teams steigern lässt. Die Umsetzung sollte möglichst bald erfolgen, aber der Hinweis auf den nächsten Sprint entfällt.

Enthalten ist aber ein kleiner Praxistipp – in Form des Hinweis, dass dafür gerne ein Eintrag ins Sprint Backlog des nächsten Sprint aufgenommen werden dürfte. Viele Praktiker empfehlen das seit Jahren, aber so adelt der Scrum-Guide das wohl als eine Art Best Practice.

Ohne das so zu nennen natürlich.

Änderungen bei den Artifakten

Die Artifakte bemühen sich vor allem um Klärung einer ewigen Streitfrage: wozu verpflichtet sich das Team eigentlich?

Bei der Umsetzung in der Praxis war das bei vielen ein Streitpunkt. Ist es das gesamte Sprint Backlog? Muss also alles abgearbeitet werden, was sich das Team auf den Teller packt? Oder ist vielleicht das Sprint-Goal entscheidend?

Das Sprint-Goal ist entscheidend. Das war schon etwas länger die Antwort, auch wenn es nach wie vor nicht jeder wahrhaben will. Im neuen Scrum-Guide ist jetzt die Selbstverpflichtung zum übergeordneten Produktziel hinzugekommen und die Definition of Done.

Übrigens: Das Wort „Commitment“ wurde jetzt in der Überschrift der jeweiligen Punkte aufgenommen. Aus meiner Sicht ein sehr eleganter Weg das deutlich zu machen.

Fazit

Man könnte sagen, der Scrum-Guide 2020 hat den Fokus stärker auf das „Warum?“ als das „Wie?“ gerichtet.

Natürlich ist bei der Überarbeitung vieles beim Alten geblieben.

Nach wie vor geht es um Teamwork, die Idee auf Grundlage des Bekannten zu entscheiden und auf gemeinsame Ziele hinzuarbeiten.

Aber es ist mit dem Produktziel und dem One-Team-Ansatz auch etwas neu hinzugekommen. Insgesamt wurde der Scrum-Guide vor allem in Hinblick auf Verständlichkeit optimiert und das aus meiner Sicht ist deutlich gelungen.

Die alles entscheidende Frage ist nur: wird sich auch in der Praxis was verändern?

(Beitragsbild von Adi Goldstein auf Unsplash)