Der beste Scrum Guide, den es je gab Scrum Guide 2020 – die Aktualisierungen unter der Lupe

Scrum Guide 2020 – die Aktualisierungen unter der Lupe

Pünktlich zum 25. Geburtstag von Scrum und drei Jahre nach der jüngsten Aktualisierung des Scrum Guide haben die Erfinder dieses wohl verbreitetsten agilen Rahmenwerks, Jeff Sutherland und Ken Schwaber, am 18. November eine Aktualisierung veröffentlicht.

Der beste Scrum Guide, den es je gab Scrum Guide 2020 – die Aktualisierungen unter der Lupe

Scrum Guide 2020 – die Aktualisierungen unter der Lupe

Pünktlich zum 25. Geburtstag von Scrum und drei Jahre nach der jüngsten Aktualisierung des Scrum Guide haben die Erfinder dieses wohl verbreitetsten agilen Rahmenwerks, Jeff Sutherland und Ken Schwaber, am 18. November eine Aktualisierung veröffentlicht.

Wir empfehlen zum Thema Vorgehensmodell
12.09.2024
1.395,00,-
Hybrides Projektmanagement - das Beste aus 2 Welten vereinen

Lernen Sie das Wichtigste beim Einsatz von hybridem Projektmanagement, damit auch Sie in Ihrem Unternehmen das Beste aus zwei Welten kombinieren. Mehr Infos

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.

Das könnte Sie auch interessieren

Drei Jahre nach der jüngsten Aktualisierung haben Ken Schwaber und Jeff Sutherland eine neue Version ihres Scrum Guide veröffentlicht. Die wichtigste Ergänzung: Values!

Unlocked Content
Vorschaubild

Immer mehr Firmen setzen auf agiles Projektmanagement. Dementsprechend wächst die Nachfrage nach qualifizierten Mitarbeitern, die idealerweise auch über die entsprechende Zertifizierung verfügen.

Unsere Abos: für jeden Bedarf das passende Abonnement

 

Das projektmagazin - unverzichtbares Nachschlagewerk und Inspirationsquelle für alle,
die in Projekten arbeiten. Ihre Vorteile auf einen Blick

Image
Wissensplattform

Zugriff auf die größte deutschsprachige Wissensplattform
für Projektmanagement  (>1.800 Artikeln und Tipps)

Image
Praxisbezogene Beiträge

Praxisbezogene Beiträge
Fachautoren schreiben aus der Praxis für die Praxis.

Image
Tools

Werkzeuge (Tools)
z.B. Checklisten und Vorlagen, Methoden mit Schritt-für-Schritt-Anleitung.

Image
Glossar

Umfangreiches Projektmanagement-Glossar
über 1.000 Fachbegriffen (deutsch/englisch)

Image
Blogbeiträge

Blogbeiträge, Themenspecials, Bücher, Stellenangebote etc.
rund um das Thema Projektmanagement

Alle Kommentare (1)

Georg
Angermeier
Dr.

Hallo Joachim,
vielen Dank für diese kompakte und so treffende Zusammenfassung der Änderungen im neuen Scrum Guide!
Mir gefällt vor allem die nun deutlich pragmatischere und entspanntere Darstellung. So wurde mein "Lieblingsstolpersatz": "Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon." ersatzlos gestrichen und klar formuliert, dass der Product Owner eben einen Sprint abbrechen kann, wenn das Sprint Goal obsolet geworden ist.
Mein neuer persönlicher Lieblingssatz des Scrum Guides ist aber: "Scrum is simple." Das kann man meines Erachtens nach nicht oft genug betonen. 12 Seiten kann jeder lesen, beherzigen und umsetzen. Vor allem aber: Ganz einfach machen!