Scrum Guide 2020 – Neuerungen & Änderungen

Pünktlich zum 25. Geburtstag von Scrum gab es gestern, am 18.11.2020, das Update des Scrum Guides von Ken Schwaber und Jeff Sutherland.

Kurz gesagt: Scrum ist und bleibt Scrum. Ein einfaches Framework, das es Teams möglich macht, mit der Arbeit an komplexen Problemen zu starten. Aber ohne lange Vorworte, hier findet ihr die Änderungen in einer schlanken Übersicht.

Ein Team, ein Fokus, ein Produkt

Was sind wir? Ein Team! Kein „Scrum Team“ mehr mit der „Untergruppe“ des „Development Team“. Aus dem Development Team wird „Developers“. Steve Ballmer hat es immer gewusst 😉

Und so gibt es nur noch ein Team! Das Scrum Team, bestehend aus Product Owner, Scrum Master und Developers, welches seinen gemeinsamen Fokus voll und ganz auf das Product Goal (siehe unten) legen kann. Somit sind alle drei in der Verantwortung, ein wertvolles und nützliches Inkrement zu liefern. Oder auch mehrere.

Multiple Produktinkremente pro Sprint

Wie gerade schon geschrieben, ist das Thema CI/CD jetzt auch im Scrum Guide angekommen. Durch Continuous Integration, Continuous Delivery und Continuous Deployment sind Teams schon lange in der Lage, mehr als eine Lieferung pro Sprint auf die Beine zu stellen. Dem wurde jetzt auch Rechnung getragen, denn jetzt sind im Scrum Guide auch mehre Lieferungen für das gleiche Produkt verankert.

Von Rollen zu Verantwortlichkeiten

Die Rollen im Scrum Framework bekommen einen neuen Namen und somit auch eine neue Aufgabe. Nachdem schon aus dem „Development Team“ die „Developers“ wurden, ist der Begriff der Rollen weggefallen und wird ersetzt. Ersetzt durch den Begriff Verantwortlichkeiten (Accountabilities genannt). Damit auch klar ersichtlich ist, dass das Team gemeinsam die Verantwortung trägt.

Selbstorganisation war gestern, heute gibt es Selbstmanagement

Bislang stand die „Selbstorganisation“ dafür, dass das Team selbst entscheiden konnte, wer im Team die Arbeit wie erledigt. Aber nachdem nun aus Rollen Verantwortlichkeiten geworden sind und das Product Goal steht, ist es nur logisch, dass wir als Team auch raus aus der reinen Selbstorganisation kommen. Selbstmanagement heißt das Schlüsselwort. Denn das Team komplett trägt die Verantwortung für das Produkt und somit soll auch das Team, mit dem Product Owner an der Spitze, entscheiden WAS umgesetzt wird. Das Team geht in die Richtung.

Neu dabei: Das „Product Goal“

Das Sprint Goal kennen wir ja alle. Es hilft dem Team, den Fokus im Sprint zu wahren. Es stellt die Leitplanken dar, an denen sich das Team orientiert. Aber was ist mit dem großen ganzen? Worauf sollen all die Sprint Ziele einzahlen? Die Antwort darauf liefert das neue „Product Goal“. Es beschreibt den zukünftigen Zustand des Produktes. Die Produkt Vision wird sozusagen in das „Product Goal“ gegossen. Und exakt darauf kann sich dann das Product Backlog fokussieren.

Alle guten Dinge sind Drei. 3 Artefakte mit 3 Commitments

Ein bisschen bleibt alles so wie es ist, Artefakte im Scrum sind es weiterhin drei (Product Backlog, Sprint Backlog und das Produkt Inkrement). Aber frisch dazu gibt es jetzt drei explizite Commitments. Sie sollen helfen, jedes Artefakt an seinem Ergebnis messbar zu machen und die Transparenz zu erhöhen.

Beim Product Backlog ist es das Product Goal, als Fokus für das Team für mehrere Sprints.

Unser Sprint Backlog wird durch das Sprint Ziel beschrieben, um zu zeigen, warum der Sprint überhaupt durchgeführt werden soll.

Und nachdem ein Produkt Inkrement auf das Product Goal einzahlt, sollte auch hier die Qualität im Auge behalten werden. Dafür dient jetzt die „DoD“ – Definition of Done –

Aus zwei mach drei: Themen im Sprint Planning

Bisher gab es im Planning nur zwei Fragen zu beantworten. Neben der Fragestellung WAS und WIE in der Form von „Was wollen wir erreichen?“ und „Wie ist unser Plan, um das zu erreichen?“ kommt jetzt auch das WARUM auf die Bühne. Und stellt die Frage „Wozu wollen wir es erreichen?“ Und diese Frage sollte das Sprint Ziel klar beantworten.

Einfache Sprache, leichter verständlich

Aus 18 Seiten wurden 11 Seiten. Der Scrum Guide ist somit deutlich kürzer und auch sehr viel einfacher zu lesen. Das Ziel ein breiteres Publikum zu erreichen ist somit besser zu erreichen. Ein klares Zeichen dafür ist die vollständige Entfernung von IT bezogenen Begriffen. Ein guter Schritt nach vorne. Aber weiterhin gilt:

Scrum – Simple to understand and difficult to master.