Was hat sich am Scrum Guide 2020 geändert?

Änderung der Scrum Rollen

Das Gute zuerst: es sind immer noch drei 😉 Im Scrum Guide ist der Begriff der "Scrum Rolle" weggefallen. Ab sofort wird von "Accountabilities" gesprochen, was sich z.B. in Führungsverantwortung übersetzen lässt. So wird der Fokus mehr auf die Verantwortlichkeiten anstatt auf die reinen Rollennamen verlegt.

Ausserdem ist der Begriff "Development Team" weggefallen. Stattdessen heißt das Development Team jetzt einfach nur noch "Developer". Damit sind alle Teammitglieder gemeint, die in irgendeiner Form am Produkt mitentwickeln, also z.B. auch ein Business Analyst. Es gibt also nur noch das Scrum Team und nicht noch ein Dev Team im Scrum Team. Das halte ich für eine sinnvolle Änderung, da in der Vergangenheit oft zu beobachten war, dass der Product Owner eher als Aussenstehender betrachtet wurde. So kam es oft zu internen Hierarchien, die in Scrum nicht gewollt sind. 

Beim Scrum Master gab es auch eine kleine Änderung vom "Servant Leader" zum "True Leader". Damit will man noch einmal verstärkt darauf hinweisen, dass der Scrum Master nicht nur auf Team Level, sondern auch auf Organisationslevel aktiv sein muss. Er ist für die Wirksamkeit des Teams verantwortlich.

Selbstorganisation vs. Selbstmanagement

Der Begriff "selbstorganisiert" wurde bisher immer nur schwammig definiert. Am Ende ist jedes System in irgendeiner Form selbstorganisiert im Rahmen seiner Systemgrenzen. Ausserdem hat der Begriff oft dazu geführt, dass man das ganze mit Anarchie gleichgesetzt hat. Dazu habe ich erst kürzlich einen Podcast gemacht.

Im Scrum Guide wurde mit der Einführung des Begriffs "Selbstmanagement" klargestellt, dass das Scrum Team für das Was, das Wann und das Wie verantwortlich sind. Sie agieren auch nicht nur innerhalb der Systemgrenzen, sondern gestalten diese Grenzen aktiv mit. Das Scrum Team wird also aktiver und weniger passiv. Ich bin gespannt, zu welchen Spannungen das in stark Hierarchie getriebenen Organisationen führt 😉

Product Goal

Über diese Änderung habe ich mich ganz besonders gefreut. Die Einführung eines Produktziels war längst überfällig. Bisher wurde dieses Thema eher stiefmütterlich behandelt. Man kann das Product Goal mit der Produktvision gleichsetzen, das schon lange Teil meines PASSION Modells ist (das man sich auf der Startseite herunterladen kann).

Mit der Einführung des Product Goals, welches gleichzeitig eines der drei Scrum Artefakte ist, führt man jetzt ein Commitment für das Product Backlog ein. Jedes Element im Product Backlog muss am Ende in das Product Goal einzahlen. Das erleichtert es zukünftig auch den Impact eines Produkts zu beschreiben.

Sprint Planning

Das Sprint Planning bestand bisher aus zwei Teilen: Das "Was?" und das "Wie?". Also was ist Teil des nächsten Sprints und wie wollen wir das konkret umsetzen. Zusätzlich gibt es ab sofort noch das "Wozu?" oder "Wofür?". Am Ende eines Sprint Plannings muss also auch geklärt werden, in wiefern der nächste Sprint auf das erreichen des Product Goals einzahlt. Viele werden das als "Sprintziel" bereits kennen, dass durch diese Änderung nochmal eine ganz andere Bedeutung erhält. Laut Jeff Sutherland, einem der Erfinder von Scrum, möchte man damit auch das "Collective Ownership" im Scrum Team stärken.

Ergänzungen zu den Scrum Artefakten

Einige der Ergänzungen sind im obigen Text schon mehr oder weniger angerissen worden. Der Scrum Guide definiert weiterhin drei Scrum Artefakte: Product Backlog, Sprint Backlog und Inkrement. Was sich jetzt ändert ist, dass jedem dieser Artefakte ein "Commitment" zugeordnet wird:

• Product Backlog (Artefakt) --> Product Goal (Commitment)
• Sprint Backlog (Artefakt) --> Sprintziel (Commitment)
• Increment (Artefakt) --> Definition of Done (Commitment)

Die ersten beiden habe ich oben bereits beschrieben. Beim Inkrement wird jetzt explizit im Scrum Guide beschrieben, dass nur die Dinge aus dem Sprint Backlog in ein Produktinkrement einfließen, die auch die DoD erfüllen. Umgekehrt heißt das, dass alle Elemente aus dem Backlog, die die DoD erfüllen automatisch Teil des Inkrements sind. Die "Definition of Done" hat also an Wichtigkeit gewonnen.

Änderungen beim Produkt Inkrement

Beim Produkt Inkrement wurde ein kleine Anpassung vorgenommen, die in vielen Teams schon längst gelebte Realität ist: es kann mehr als ein Produkt Inkrement pro Sprint geben. Man muss also nicht bis zum Sprint Review warten, bis ein neues Produkt Inkrement "live" geht. In der Vergangenheit hat das sehr häufig zu Missverständnissen geführt.

Fazit

Ich habe mich besonders über die Einführung des Product Goals und den Wegfall des Begriffs des "Development Teams" gefreut. Endlich sind alle Teil EINES Teams mit einem gemeinsamen Fokus auf das Product Goal. Auch darf man das Thema Selbstmanagement nicht unterschätzen. Scrum Teams sollen raus aus der Opferrolle und ihre Umgebung aktiv mitgestalten. 

Ich bin gespannt, wie diese Anpassungen in der Praxis ankommen. Insgesamt ist der Scrum Guide jetzt noch knackiger mit gerade einmal 13 Seiten. Ausserdem wurde explizit der Fokus auf die Softwareentwicklung entfernt.

Wenn Du wissen willst, wie Du Scrum in Deinem Unternehmen effektiv einführen kannst, dann melde Dich gerne bei mir. Klicke einfach rechts oben auf "Strategietermin vereinbaren". Ich freue mich auf Dich.

Hier geht es zur ausführlichen Podcast Episode: