18.11.2020 | Pesche
Am 18.11.2020 haben Ken Schwaber und Jeff Sutherland eine neue Version des Scrum Guides veröffentlicht. Die gute Neuigkeit zuerst: Scrum is still Scrum!
Nebst sprachlichen Vereinfachungen und Kürzungen gibt es auch inhaltliche Anpassungen, welche wir uns zusammen anschauen möchten. Folgende Änderungen/Klärungen erscheinen mir wichtig:
Die Rollen sind neu Accountabilites
Das Development Team wurde umbenannt in Developers
Der Servant Leader ist verschwunden
Das Sprint Planning adressiert neu auch das Warum und nicht nur das Was und Wie
Jedes Artefakt hat ein Commitment
Das Increment wird während des Sprints geboren
Stakeholder Collaboration ist Sache des Scrum Teams
Der Product Owner als Entscheider über den Release wird nicht mehr erwähnt
Bei den folgenden Interpretationen handelt es sich um meine persönliche Meinung.
Im deutschen Sprachgebrauch verschwindet der Unterschied zwischen Accountability und Responsibility, wenn man beide Begriffe als Verantwortung übersetzt. Übersetzt man Accountability aber mit Rechenschaftspflicht oder Haftung, sind wir viel näher an der Bedeutung im Scrum Guide. Eine Accountability kann nicht delegiert werden, eine Responsibility schon. Das Scrum Team hat die Rechenschaftspflicht, jeden Sprint ein wertvolles und nützliches Increment zu erstellen. Im Scrum Team gibt es drei spezifische Accountabilities: Die Developers, den Product Owner und den Scrum Master.
Der Sammelbegriff Developers erspart uns zukünftig die Diskussion über Development Team und Scrum Team. Jetzt ist definitiv klar, dass alle gemeint sind, wenn vom Team gesprochen wird und es kein Team im Team mehr gibt. Die Accountability Developers besitzen alle, die sich dazu verpflichten, im Sprint einen beliebigen Aspekt eines verwendbaren Increments beizusteuern.
Der Scrum Master wird nicht mehr als Servant Leader, sondern als “true leader who serves the Scrum Team and the larger organization” beschrieben. Damit erhält das Scrum Team mehr Freiheit, den Grad an Führung zu bestimmen, den es wirklich benötigt.
Das Sprint Planning adressiert neu explizit das “Warum ist der Sprint wertvoll?”, vor dem bekannten “Was können wir in einem Sprint realisieren?” und “Wie setzten wir die gewählte Arbeit um?” Bei dem Warum erklärt der Product Owner den Wert der angedachten Tätigkeiten. Basierend darauf kann das Scrum Team das Sprint Goal definieren.
Jedes Artefakt hat jetzt ein Commitment (Verpflichtung), um sicherzustellen, dass die gewünschten Informationen bereitgestellt und somit die Transparenz gewahrt wird. Das Sprint Goal ist das Commitment für den Sprint und die Definition of Done dasjenige für das Increment. Neu ist das Product Goal das Commitment für das Product Backlog, welches einen zukünftigen Zustand des Produktes beschreibt. Sprint Goals aneinandergereiht führen zum Product Goal, und Product Goals aneinandergereiht führen zur Product Vision (wobei Vision nicht mehr erwähnt wird). Das Scrum Team fokussiert sich immer nur auf ein Product Goal zur selben Zeit.
Das Increment ist nicht mehr die Summe aller abgeschlossenen Product Backlog Items während eines Sprints, sondern ein Increment entsteht, sobald ein Product Backlog Item die DoD erfüllt. Somit steht dem kontinuierlichen Releasing eigentlich nichts mehr im Weg. Das Review als Value Gate ist explizit unerwünscht.
Die Stakeholders werden viel häufiger und prominenter erwähnt als früher. Stakeholder Collaboration ist klar eine Verantwortung vom Scrum Team, der Product Owner repräsentiert ihre Bedürfnisse im Product Backlog und der Scrum Master erleichtert die Zusammenarbeit und beseitigt allfällige Barrieren zwischen ihnen und dem Scrum Team.
Unter Release verstehe ich die Freisetzung von Wert zum Benutzer. In der früheren Version vom Scrum Guide wurde dem Product Owner explizit die Kompetenz zum Releasen zugesprochen. Diese Passagen wurden im Scrum Guide 2020 entfernt. Da der Product Owner aber weiterhin dafür accountable ist, den Wert des Produktes zu maximieren, könnte man ihm diese Kompetenz weiterhin implizit zusprechen. Andererseits habe ich in der Praxis nie erlebt, dass ein Product Owner gegen die Empfehlung der Entwickler entschieden hat, sein Product produktiv zu setzten. Dementsprechend könnte man daraus schliessen, dass der Release-Entscheid seit jeher eher ein Gemeinschaftsakt war und daher die Kompetenz im Scrum Team besser angesiedelt ist.
Einerseits finde ich es schade, ist der Scrum Guide 2020 hier nicht präziser formuliert und lässt Raum für Interpretationen. Anderseits freue ich mich auf die spannenden und anregenden Diskussionen.
Wie wir alle wissen, ist es viel einfacher zu addieren als zu kürzen. Ich denke, der Scrum Guide 2020 reduziert sich sehr gut auf die minimale und ausreichende Beschreibung eines Frameworks zur Lösung komplexer Probleme. Den wahren Mehrwert erfahren wir durch die effiziente Anwendung und nicht durch die Beschreibung. ScrumOn!