Brandneuer Scrum Guide 2020 – fünf schlanke Unterschiede, die einen Unterschied machen

Das Wichtigste vorab: Ab 10. Januar 2021 basieren alle scrum.org-Prüfungen auf dem am 18. November 2020 vorgestellten neuen Guide. All unseren Kursteilnehmern, die sich ihre Prüfungen als persönliches Geschenk für die Weihnachtsferien aufgehoben haben, empfehlen wir deshalb:

Haltet euch ran, der 2017er-Guide wird jetzt sehr schnell veralten!

Wir haben den 2017er und 2020er Guide sorgfältig verglichen und sehen fünf wichtige Unterschiede, die wir im Folgenden mit unseren Bewertungen aufführen.

Seit Erscheinen der ersten Version des Guides von Schwaber und Sutherland dürfte es sich wohl um die größte Überarbeitung handeln, die unsere beiden mehr als angegrauten agilen Pioniere in den vergangenen drei Jahren ausgeheckt haben. Aber keine Angst: Scrum bleibt Scrum!

Diese Unterschiede machen einen Unterschied

1. Scrum wird „more lean“ (exakt um 31,57 %)!
Bemerkenswert für diese seltsamen Zeiten, begegnen unsere Scrum-Erfinder unserer immer komplexer und unberechenbarer werdenden Welt nicht mit mehr, sondern mit weniger Regeln und Details! Statt 19 Seiten umfasst der neue Scrumguide nur noch schlanke 13 Seiten.

Gespart wird etwa an Beschreibungen von Events wie den Sprint Reviews, die auf ein Drittel geschrumpft sind. Das zieht sich durch, und so kommen auch Daily Scrum und Retro mit der Hälfte an Beschreibung aus.

2. Scrum wird noch offener, und zwar durch weniger Vorschriften
Wer nach allen Seiten offen ist, ist ja bekanntlich nicht ganz dicht: Deshalb braucht es ein paar Spielregeln im sozialen und professionellen Miteinander. Nur nicht mehr ganz so viele und detailierte, dachten sich wohl unsere beiden Helden, und haben einige „nitty-gritty“-Vorschriften ersatzlos gestrichen.

Vorgaben wie dass das Development Team maximal 10% seiner Kapazitäten für das Backlog-Refinement aufwenden darf, finden sich nicht mehr, PBIs (Product Backlog Items) werden nicht mehr „estimated“, sondern „sized“ (das dürfte die „Scrum-mit-Kanbaner“ freuen) und die von manchem als hochnotpeinlich empfundenen drei Fragen, die jeder Developer im Daily Scrum beantworten musste, tauchen gar nicht mehr auf. Fun fact: Der mittlerweile jahrzehntelang heftig umstrittene Begriff „Requirements“ ist verschwunden – nicht nur Kent Beck wird’s freuen.

3. Scrum unterstreicht jetzt einen „One-Team-Approach“
Es gibt nur noch EIN Team, nämlich das Scrum Team, kein „Team-in-Team“-Development-Team mehr. Dieses Scrum-Team umfasst die „Accountabilities“ Product Owner, Scrum Master und Developer. Der Begriff der Rolle fällt ganz weg, es gibt kein eigenständiges Development Team mehr, sondern nur noch Developer, die Teil des Scrum Teams sind. Das bedeutet weniger Abgrenzungsmöglichkeiten, mehr gemeinsame Team- und Zielfokussierung. Wir finden’s gut.

4. Mehr „Wozu?“, weniger „Womit?“
Anstelle von Formalismen, die das „Womit?“ beschreiben, rückt das „Wozu?“ in den Vordergrund. Dazu wurde zu jedem der drei Artefakte eine Verpflichtung („Commitment“) ergänzt. Das Commitment für das Product Backlog ist das neu eingeführte „Product Goal“ (der Begriff der Vision taucht im Guide nicht mehr auf), für das Sprint Backlog das bekannte Sprint Goal und für das Increment die Definition of Done. Insgesamt also stärkere Fokussierung auf langfristige und kurzfristige Geschäfts- und Qualitätsziele.  

5. DevOps lässt grüßen - Sprints dienen nicht als „Release-Gates“
Mit einem aus unserer Sicht seit 25 Jahren verbreiteten Missverständnis wird durch ein paar klarstellende Passagen aufgeräumt: Sprints und deren Reviews dienen NICHT als Antwort auf die Frage, ob wir jeweils das Ergebnis (Increment) am Ende eines, zum Beispiel, zweiwöchigen Zyklus releasen sollen oder nicht. Selbstverständlich können Scrum Teams sofort jedes „done“ PBI freigeben und produktiv setzen – und somit vollständig das durch DevOps so populär gewordene Konzept einer Continuous Delivery realisieren.

Sprint Reviews dienen in einem solchen Szenario dazu, eine vollständige Ende-zu-Ende-Betrachtung abzuschliessen: Wie kommt das jeweilige neue PBI (Feature, Bugfix, …) beim Kunden an, wie ist seine Nutzung? Zusammengefasst: Sprints dienen als Verbesserungszyklen und Takt, nicht als „Release-Gates“.

Alles in Allem

Uns gefällt der neue Scrumguide 2020. Modern, offen, aber irgendwie auch zurück zu seinen Wurzeln. Ken Schwaber hat mal in den Neunzigern seine Sicht auf den Kern von Scrum in einem Blogposting wiedergegeben: Empirisches Vorgehen, Anwendung von Lean-Prinzipien und ein autonomes, selbstorganisiertes Team. Er ist sich treu geblieben.

Ab sofort: Selbstverständlich behandeln wir in all unseren agilen Trainings ergänzend die wichtigsten Änderungen in Scrum!

Den neuen SCRUM Guide könnt Ihr hier herunterladen.