Heute, am 18. November 2020, pünktlich zum 25. Geburtstag von Scrum, haben Ken Schwaber und Jeff Sutherland den Scrum Guide aktualisiert.
Um eines gleich vorwegzunehmen: Scrum bleibt Scrum. Ein einfaches Rahmenwerk, welches es Teams ermöglicht, mit der Arbeit an komplexen Problemen zu beginnen. Und der Scrum Guide 2020 ändert daran nichts.
Einige Dinge sind jedoch neu und denen widmen wir uns jetzt.
Der Scrum Guide ist keine Anleitung, wie Scrum umgesetzt wird
Die Intention des Scrum Guides ist es, das Scrum Rahmenwerk in möglichst klarer und präziser Weise zu beschreiben. Obwohl der Scrum Guide über die letzten Jahre kürzer geworden ist, erklärte er häufig noch, wie Scrum umgesetzt werden kann.
Der neue Scrum Guide beschreibt Scrum als das, was es ist: Ein minimales Rahmenwerk, welches Menschen, Teams und Organisationen hilft, durch adaptive Lösungen für komplexe Probleme Wert zu generieren.
Dazu wurden Passagen entfernt oder weiter abgemildert, nämlich
- die drei Fragen im Daily Scrum;
- dass sich die Mitglieder des Development Teams häufig noch nach dem Daily Scrum treffen;
- verpflichtenden Attribute eines Product-Backlog-Eintrags;
- die 8 Elemente des Sprint Reviews;
- die detaillierten Gründe, wozu die Sprint Retrospektive durchgeführt wird;
- Empfehlung, wieviel Kapazität des Development Teams das Refinement üblicherweise beansprucht;
- wie die Erreichung der Ziele im Product Backlog überwacht werden kann.
In der passenden Situation ist jede dieser Beschreibungen oder Anleitungen weiterhin wertvoll. Sie sollten jedoch in ihrem eigenen Kontext beschrieben werden und nicht im Scrum Guide.
Wenn die Anleitungen im Scrum Guide von 2017 hilfreich für dich sind, dann verwende sie bitte auch weiterhin!
Ein Scrum Team ist ein Team
Das Development Team ist ein Grundpfeiler von Scrum. Viele der Ideen in Scrum sind mit dieser Rolle verbunden. Trotzdem führt es häufig zu Verwirrungen: Warum ist das Development Team gleichzeitig eine Rolle und ein Team? Warum gibt es in einem Scrum Team ein weiteres Team? Ist ein Scrum Developer auch eine Rolle?
Um diese Verwirrungen aufzulösen und es irrtumsfrei zu formulieren, wurde die Rolle Development Team zu Developer: Was das Scrum Team zu einem Team macht, welches aus einem Scrum Master, einem Product Owner und Developern besteht.
Es gibt ein Product Goal
Um Scrum Teams dabei zu unterstützen, sich auf ein größers und wertstiftendes Ziel zu fokussieren, wurde im Scrum Guide 2020 das Product Goal eingeführt. Es beschreibt einen zukünftigen Zustand des Produkts. Das Product Goal hält fest, wozu das Scrum Team die Arbeit am Produkt erledigt.
Das Product Goal unterstützt ein Scrum Team auf zweierlei Weisen:
- Es kann als Ziel für das Scrum Team dienen, um dessen zukünftige Arbeit zu planen. Jeder Sprint sollte das Produkt näher zum Product Goal bringen.
- Es hilft dem Scrum Team, den Fortschritt seiner Arbeit am Product Backlog sichtbar und messbar zu machen.
Somit ist das Product Goal ein richtungsweisendes Statement, das dem Scrum Team und Stakeholdern einen Kontext und eine Richtung für die zu erledigende Arbeit bietet.
Jedes Artefakt enthält ein Commitment
Im Scrum Guide 2017 hatte das Sprint Goal und die Definition of Done keinen festen Platz. Sie waren zweifelsohne essentiell für den Erfolg eines Scrum Teams, aber weder Bestandteil einer Rolle, Events oder Artefakts. Im neuen Scrum Guide 2020 haben sie einen Platz gefunden, welcher ihrem Stellenwert gerecht wird. Sie stellen das Commitment zu einem Artefakt dar.
- Für den Product Backlog ist es das Product Goal.
- Für den Sprint Backlog ist es das Sprint Goal.
- Für das Inkrement ist es die Definition of Done.
Die Commitments beschreiben die Artefakte und liefern somit Klarheit über den Zweck, Kontext und Wert des Artefakts. Sie verbessern die Transparenz und bieten eine Möglichkeit, den Fortschritt gegen dieses Artefakt zu messen. Die Commitments existieren, um Empirie und die Scrum Werte für das Scrum Team und seine Stakeholder zu stärken. Wenn du lernen willst, wie du die Commitments am Besten in deinem Scrum Team umsetzt, dann besuche mein nächstes Professional Scrum Master Training.
Das Sprint Planning besteht jetzt aus drei Aspekten
Als Commitment hat das Sprint Goal im Sprint Backlog jetzt einen festen Platz. Es wird im Sprint Planning vom Scrum Team gemeinschaftlich definiert. Um dem Ausdruck zu verleihen, beantwortet das Scrum Team im Sprint Planning neben den Punkten,
- welche Product-Backlog-Einträge im Sprint fertig gestellt werden können und
- wie die ausgewählte Arbeit erledigt werden kann,
jetzt auch die Frage,
- warum dieser Sprint wertvoll für die Stakeholder ist.
Mit den Antworten auf die ersten beiden Punkte wird der Plan für den Sprint erstellt. Die Antwort auf den letzten Punkt wird im Sprint Goal festgehalten. Alles zusammen stellt den Sprint Backlog am Ende des Sprint Plannings dar.
Scrum Teams managen sich selbst
Im Scrum Guide von 2017 ist das Development Team als selbstorganisierend beschrieben, das heißt das Development Team bestimmt eigenständig, wer und wie die Arbeit erledigt werden soll.
Der Scrum Guide 2020 betont, dass das Scrum Team als Ganzes sich selbst managt. Es entscheidet, wer und wie die Arbeit erledigt werden soll und an was gearbeitet werden soll. Wobei weiterhin erwartet wird, dass die Developer ihre eigene Arbeit managen.
Was Selbstmanagement für Scrum Team genau bedeutet, wird wie folgt beschrieben:
Das Scrum Team ist für alle produktbezogenen Aktivitäten verantwortlich, die von der Zusammenarbeit der Stakeholder, über die Überprüfung, Wartung, den Betrieb, das Experimentieren, die Forschung und Entwicklung, bis hin zu allen weiteren erforderlichen Aktivitäten reichen. -- Scrum Guide 2020
Diese Veränderung unterstreicht, wie die Ersetzung von Development Team durch Developer, dass ein Scrum Team ein Team ist. Ein Team, welches dafür verantwortlich ist, eigenständig ein wertvolles und nützliches Inkrement zu erstellen.
Der Scrum Guide ist einfacher geschrieben
Dadurch, dass der Scrum Guide 2020 weniger beschreibt, wie die Elemente von Scrum umgesetzt werden sollen, ist er nicht nur kürzer, sondern auch einfacher zu lesen.
Diese Fokussierung auf das Wesentliche macht ihn für ein breiteres Publikum interessant. Dies wird dadurch unterstützt, dass alle verbleibenden Rückschlüsse auf die IT Arbeit, wie zum Beispiel die Begriffe Testen, System, Design, Anforderung und vieles mehr, vollständig entfernt wurden.
Diese 7 Dinge, die im Scrum Guide geändert wurden, untermauern nochmal, dass Scrum immer noch nur Scrum ist. Ein einfaches Rahmenwerk, welches es Teams ermöglicht, mit der Arbeit an komplexen Problemen zu beginnen. Es kommt auf die Intelligenz, Erfahrung und Hingabe der Anwender an, um Scrum zum Leben zu erwecken und Produkte von höchst möglichem Wert zu entwickeln.
Willst du noch mehr erfahren und keine neuen Artikel mehr verpassen? Dann warte nicht länger und abonniere meinen 👉Newsletter.