Ich fasse hier die sieben großen Änderungen (siehe dazu auch die offizielle Versionshistorie) im Vergleich zur Version von 2017 in drei Abschnitten zusammen, und bewerte deren Bedeutung für die Praxis. Eines vorweg: Für mich – als jemand der Scrum außerhalb der IT einsetzt und über die Jahre unzählige Scrum Teams begleitet hat – ist der Versionssprung auf den Scrum Guide 2020 der wichtigste Sprung in der Geschichte des Scrum Guide.

1. Scrum für alle

Für den neuen Scrum Guide haben die Autoren einige konkrete Anweisungen und Definitionen entfernt und den Guide dadurch deutlich verschlankt (12 statt 17 Seiten Inhalt). Verschwunden sind zudem sämtliche Begriffe mit Bezug zur IT oder zur Produktentwicklung. Der Konsistenz und Einfachheit halber gibt es zwar noch ein "Product" und "Developer", der Scrum Guide stellt aber klar, dass damit komplexe Probleme und Menschen mit entsprechender Expertise gemeint sind.

Dadurch tragen Sutherland und Schwaber dem inzwischen sehr breiten Einsatzspektrum von Scrum Rechnung (Marketing, Qualitätsmanagement, Schulen usw.) und beenden die früher immer wieder anzutreffende Diskussion über mögliche Einsatzbereiche.

2. Ein Team, ein Ziel

Product Owner, Scrum Master und Entwicklungsteam. Statt letzterem gibt es nun Entwickler (Developer), sodass das Scrum Team das einzige Team in Scrum ist. Auch der Begriff der Scrum-Rollen ist Geschichte, er wurde ersetzt durch Verantwortlichkeiten. Das Scrum Team als Ganzes ist dafür verantwortlich, dass das "Product Goal" erfüllt wird, indem es das Product Backlog Sprint für Sprint abarbeitet.

Diese Gesamtverantwortung war zwar zuvor schon in Scrum verankert, jedoch mildern deren Betonung sowie die Abschaffung des Entwicklerteams als Team im Team den kulturell oft vorhandenen Bruch zwischen denjenigen, die das "Was" bestimmen und jenen, die das "Wie" umsetzen. Die neue, klare Definition verhindert Diskussionen über die Zuständigkeit – auch der Product Owner und der Scrum Master sind nun explizit mitverantwortlich für die Ergebnisse.

Der Scrum Guide macht hier auch noch einmal klar, dass es für ein Team zu einem Zeitpunkt nur ein Product Goal geben kann (es können jedoch mehrere Teams gemeinsam an einem Goal arbeiten). Dass ein Mensch oder eine Organisationseinheit an Effektivität verliert, sobald er/sie mehrere Ziele gleichzeitig verfolgt, sollte eigentlich selbstverständlich sein. Die in der Praxis häufig erlebte Überlastung und Defokussierung zeigt jedoch, wie wichtig eine solche klare Aussage ist.

Auch an einer zunächst unscheinbaren Stelle spiegelt sich die hervorgehobene Gesamtverantwortung wider: Im alten Scrum Guide stand, dass das Entwicklungsteam das "Wie" (und das "Wer") selbstorganisiert umsetzt. Da es jetzt nur noch ein Team gibt, muss auch das "Was" (vertreten durch den Product Owner) mit in die Definition der Arbeitsweise aufgenommen werden: Der Scrum Guide spricht jetzt davon, dass das gesamte Scrum Team "selbstgemanagt" ist, das trifft die schon lange in Scrum angelegt Grundintention deutlich präziser als die alte Definition eines selbstorganisierten Entwicklungsteams.

3. Frag immer erst warum

Bisher bestand das Sprint Planning aus den beiden Aspekten "Was" und "Wie": Das Entwicklungsteam zog sich Items aus dem Product Backlog (PBIs) in das Sprint Backlog ("Was") und leitete aus diesen seinen Plan für den Sprint ab, oft in Form von Aufgaben ("Wie") zu den jeweiligen dem Product Backlog Items. Im neuen Scrum Guide wird nun dem Sprint Backlog (dieses enthält ja den Plan für den Sprint) ein dritter Aspekt hinzugefügt: das "Warum" (Buchtipp hierzu).

Das bisher auch schon vorhandene Sprint Goal erhält dadurch einen größeren Stellenwert. Das ist gut, denn die Erfahrung zeigt, dass es mitunter schwierig ist, ein sinnvolles Sprint Goal zu bestimmen. Oft liegt das daran, dass die Sortierung und der Zuschnitt der Backlog Items optimiert werden sollte. Manche Teams scheuen diesen Aufwand und verzichten lieber darauf, ein Sprint Goal zu definieren. Dieser Ausweg ist nun (zurecht) nicht mehr möglich.

Die Erhöhung von Fokus und Commitment durch die Vereinbarung von Zielen beschränkt sich jedoch nicht nur auf die beiden Backlogs, sondern zieht sich durch bis zum dritten Artefakt, dem Increment. Jedem Artefakt ist nun ein sogenanntes Commitment zugeordnet, welches das entsprechende Artefakt präzisieren soll: Für das Product Backlog ist es das Product Goal, für das Sprint Backlog das Sprint Goal und für das Increment die Definition of Done. Dadurch gibt es für diese drei bisher "frei schwebenden" Vereinbarungen jeweils einen definierten Platz.

Mein Fazit

Im Scrum Guide 2020 werden Verantwortung und Fokus noch klarer herausgestellt und stehen damit noch deutlicher im Konflikt zu den mancherorts etablierten ineffektiven Vorgehensweisen – eine Chance, um besser zu werden. Im die neue Version wurde auch explizit aufgenommen, dass Scrum nur als Gesamtkonzept seine volle Wirkung entfalten kann. Wer Elemente weglässt, muss mit den dadurch verursachten Nachteilen leben. Durch das Entfernen der Bezüge zur Softwareentwicklung fällt ein gerne genutztes Argument gegen den Einsatz von Scrum weg. Scrum steht damit jedem offen, der mit hoher Effektivität komplexe Probleme lösen möchte.

Seit einem Vierteljahrhundert setzen Millionen von Anwendern Scrum ein und durch deren Feedback wird Scrum ständig weiterentwickelt. Aktuell scheint kein besserer Ansatz für die teambasierte Lösung von komplexen Problemen verfügbar zu sein, doch auch der Scrum Guide 2020 bildet nur den aktuellen Erfahrungsstand ab, der Guide wird sich weiterhin entwickeln und noch weiter verbessern. Bleiben wir gespannt.