Der Scrum Guide 2020 aus Sicht von Objectives & Key Results - Teil 1

It’s coming home
It’s coming home
It’s coming
Football’s coming home …

The Lightning Seeds, Frank Skinner, David Baddiel

Am 18.11.2020 präsentierten Ken Schwaber und Jeff Sutherland gemeinsam den aktualisierten Scrum Guide 2020. Nach dem Lesen des neuen Guides habe ich das Gefühl, dass Scrum zu seinen Wurzeln zurückgekehrt ist. Scrum ist heimgekehrt zu dem, was es eigentlich immer sein wollte, aber lange nicht mehr war: Ein agiles Framework! Scrum’s coming home!

In diesem Artikel beschreibe ich die Änderungen von Scrum aus Sicht von Objectives & Key Results (OKR), einem Framework für ein agiles Ziel-Management in der Organisationsentwicklung.

Warum sollte man sich mit dem Scrum-Guide überhaupt beschäftigen?

Scrum ist etabliert und ein sensationeller Erfolg geworden. Gibt es überhaupt noch Menschen, die nichts von Scrum gehört haben? Und betrifft eine Überarbeitung des Scrum-Guides die tägliche Praxis überhaupt?

Das sind Frage, die ich mir auch gestellt habe und ich bin zur Antwort gelangt: Der neue Scrum-Guide hat Bedeutung. Die Amerikaner würden sagen: It matters!

Die agile Arbeit wird mittlerweile so stark durch Scrum geprägt, dass agiles Arbeiten fälschlicherweise oft mit Scrum gleichgesetzt wird. Zugleich gibt es im bislang gelebten Scrum-Prozess deutliche Schwächen, von denen ich einige bereits in meinen Artikel “Die agile Geschwindigkeitslüge” beschrieben habe. Aus meiner Sicht hat Scrum mit dem neuen Scrum Guide 2020 einen letzten großen Entwicklungsschritt vollzogen. Ein Schritt, der Scrum wieder näher in die Familie der agilen Frameworks zurückbringt. Wenn die Ausbildung künftiger Scrum-Master auf Grundlage des neuen Scrum-Guides 2020 erfolgt, ist das sowohl für das Thema agile Arbeit, als auch für die beteiligten Teams ein Segen.

Warum, Was und Wie – Die drei Ebenen der Arbeitsorganisation

Als wäre der Golden Circle von Simon Sinek jetzt auch in Scrum angekommen, so liest sich das Why, What & How des neuen Guides.

Worum geht es? Das Framework Scrum beschäftigte sich in der Vergangenheit fast ausschließlich mit dem “Was” und dem “Wie”. Der Product Owner verantwortete mit dem Backlog und der Sprintplanung das “Was”, also welche Arbeit erledigt werden muss. Das Entwicklerteam kümmerte sich um das “Wie”, also die Form der Erledigung. Völlig außen vor blieb bislang das “Warum”, also der Grund, warum die Dinge überhaupt gemacht werden sollten. Die Priorisierung im Backlog erfolgte über den Business Value, ein abstrakter Begriff, der in der täglichen Arbeit oft keine Hilfe war. Schlimmer, stattdessen kenne ich sehr viele Teams, bei denen nach Aufwand priorisiert wurde.

Bislang bildete die Produktvision eine lose Klammer für das Backlog. Die Produktvision stellt eine grobe Beschreibung des zu entwickelnden Produkts dar und wurde im Scrum-Guide bis zur Version 2017 eigentlich nur in einem Nebensatz erwähnt:

Das Inkrement ist ein Schritt in Richtung einer Vision oder eines Ziels

Und dementsprechend oft habe ich eine gut ausformulierte Produktvision vorgefunden: Nie!

Im Scrum-Guide 2020 gibt es jetzt eine Bedeutungshierarchie, die sich durch das gesamte Dokument zieht und insbesondere in der Sprintplanung, der Herzkammer des Scrum-Prozesses, thematisiert wird: Das Warum, das Was und das Wie.

Das “Warum” und die Verpflichtung auf ein Produktziel

Auf der obersten Ebene des “Warum” steht das neu eingeführte Produktziel (Product Goal). Das Produktziel ist ab jetzt für den Scrum-Prozess verpflichtend. Der neue Scrum-Guide schreibt zum Produktziel:

Produktziel: Das Produktziel beschreibt einen zukünftigen Zustand des Produkts, der dem Scrum-Team als Basis für die Planung dienen kann. Das Produktziel befindet sich im Product Backlog. Im Rest des Product Backlogs wird definiert, was das Produktziel erfüllen wird.

Damit ist das Backlog nicht mehr das Sammelbecken aller möglichen Anforderungen, sondern enthält nur noch Punkte, die auf das Produktziel “einzahlen”. Dave West¹, der augenscheinlich an dem neuen Scrum-Guide mitgearbeitet hat, schreibt in seinem Blogbeitrag zum Produktziels:

Das Wort “Ziel” ist beabsichtigt, da es zwei Dinge beschreibt:

Es ist etwas, wonach man strebt, und es ist messbar, wenn man es erreicht hat.

Das ist genau die Zieldefinition, die ein gutes OKR ausmacht: Eine Richtung und eine messbare Beschreibung, wie die Zielerreichung aussieht.

Warum hat das Produktziel für mich so eine Bedeutung? Seien wir ehrlich, es ist doch völlig egal wie hoch die Team-Velocity ist. Es ist auch egal, was das Team an tollen und coolen Features aus dem Backlog bearbeitet hat. Die Arbeit kann völlig wertlos sein, wenn am Ende die Antwort auf die einzig wichtige Frage fehlt:

Was ist (verdammt noch mal) der Nutzen für den Kunden?

Diese Frage nach dem “Warum” habe ich bei Scrum bislang schmerzlich vermisst. Genau das ist der Grund, warum der Lean- und OKR Experte Felipe Castro das Framework Scrum lange als Agile für Lieferteams bezeichnet hat. Bislang hatte er leider recht damit.

Ich glaube, das Produktziel wird künftig, wenn Scrum richtig gelebt wird, das wichtigste Artefakt² im Scrum-Prozess werden.

Das Sprint-Ziel: Es kann nur eines geben

Auf der Ebene der Sprints wurde ebenso das Sprint-Ziel gestärkt. Bis zur Version 2017 war das Sprint-Ziel eher eine Rationalisierung der Inhalte der Sprintplanung. Das bedeutet, dass zusammen mit den Inhalten der Sprintplanung vom Team auch ein Sprint-Ziel aufgestellt werden sollte.

Leider musste ich feststellen, dass ich in der freien Wildbahn nur wenige richtig gute Sprint-Ziele gesehen habe. Entweder, und das war leider die Mehrzahl, gab es überhaupt keine Sprintziele oder es gab direkt ganz viele für einen Sprint. Hilfreich war weder das eine, noch das andere.

Mit dem neuen Scrum Guide 2020 führt das Sprint-Ziel die Arbeit im Sprint. Das Scrum-Team erarbeitet gemeinsam das Sprint-Ziel und zeichnet sich für die Erfüllung des Sprint-Ziels verantwortlich. Wir kommen endlich raus aus der Tretmühle der Ticket-Abarbeitungsmaschine, für die Scrum in der Praxis oft bekannt war.

Konsequent zu Ende gedacht bedeutet es: Es ist eigentlich egal, welche Dinge im Sprint bearbeitet werden, Hauptsache, das Sprint-Ziel wird umgesetzt und das Team rückt dem Produktziel näher. Gut so!

Der neue Scrum-Guide schreibt dazu:

Das Sprint-Ziel ist das einzige Ziel für den Sprint. Obwohl das Sprint-Ziel eine Verpflichtung der Entwickler ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die zur Erreichung dieses Ziels erforderlich ist. Das Sprint-Ziel schafft auch Kohärenz und Fokussierung und ermutigt das Scrum-Team, gemeinsam und nicht an getrennten Initiativen zu arbeiten.

Ich hoffe, das ist der erste Schritt dazu, dass Teams nicht mehr in maximaler Arbeitsteilung ihre Tickets abarbeiten. Es ist hoffentlich auch ein Schritt in Richtung Pairing oder sogar Mobbing. Never Code alone!

Das “Was” und das Ende des endlosen Schätzens

Die zweite Ebene ist das “Was”. Die Organisation des “Was” war bislang die eigentliche Domäne von Scrum. Das “Was” dient der Klärung der Frage, was das Team jetzt als nächstes bearbeiten soll oder nicht.

Doch es gab bislang ein Problem. Die Priorisierung von Aufgaben war ein leidiges Thema, denn priorisiert wurde nach einem Begriff, den niemand wirklich fassen konnte: Dem Business Value. Ticket-Tools, wie Jira oder Mantis verschärften das Problem noch, weil diese Tools nichts vergaßen. Das ist für das Management von Störungen (Issues), für das diese Tools eigentlich gedacht waren, auch in Ordnung. Im Ergebnis wurden Backlogs immer größer und größer. Ich kenne Backlogs mit mehreren 1000 Einträgen.

Jedenfalls wurde priorisiert, geschätzt, gegroomed und refined, was das Zeug hielt. Diese Konstrukte sind aus meiner Sicht ein Zeichen von Verschwendung.

Die No-Estimates-Bewegung setzte hier einen Kontrapunkt und stellt zu Recht die Frage, in welcher Form dieses “Schätzen” überhaupt zur Produktentwicklung beiträgt?

Jetzt gibt es einen klaren Rahmen zur Priorisierung und dieser wird durch das Produktziel, also dem “Warum”, gesetzt. Damit wird Priorisieren einfacher. Die einzige Frage lautet jetzt:

“Mit welchem Thema kommen wir in diesem Sprint dem Produktziel entscheidend näher?”

Die Antwort auf diese Frage ist das Sprintziel, dass jetzt mit Aufgaben, Stories oder was auch immer, gefüllt werden kann.

Im Scrum-Guide 2020 wurde der Begriff “Schätzen” entfernt

Folgerichtig ist das Wort “Schätzen” aus der Version 2020 des Scrum-Guides eliminiert worden. An Stelle des “Schätzens” tritt der neue Begriff des “Sizing”, der mir deutlich besser gefällt. Die anstehenden Aufgaben werden so geschnitten, dass diese als Inkremente im Sprint bearbeitet werden können.

Leute, packt eure Planning Poker Karten weg. Sie haben Spaß gemacht, aber seien wir ehrlich, wenn ihr Planning Poker macht, heißt das, dass ihr kein klares Ziel habt und das “Sizing” der Aufgaben nicht stimmt.

Das “Wie” und das selbst geführte Team

Jetzt, wo das Klein-Klein der Backlog-Priorisierung weg ist, gibt es auch eine interessante Wendung beim Thema Selbstorganisation. Aus der Selbstorganisation wird das Selbstmanagement oder das selbstführende Team.

Was ist der Unterschied? In demArtikel “The Difference between self management and self organization” wird der Unterschied sehr gut beschrieben:

• Selbstorganisiert bedeutet, dass das Team über das “Wie” der Aufgabenerledigung entscheidet und verantwortlich ist. Das war die Aufgabe des alten “Entwicklerteams” in Scrum³.
• Selbstgemanagt oder selbst geführt bedeutet, dass das Team sowohl für das “Was” als auch für das “Wie” verantwortlich ist. Das “Was” ist jetzt nicht mehr eine einsame und oftmals nicht nachvollziehbare Entscheidung des Product-Owners, sondern wird vom gesamten Scrum-Team verantwortet.

Das “Warum” wird zur eigentlichen Führungsaufgabe, die jetzt im Kontext einer ganzen Organisation auch außerhalb des Scrum-Teams definiert werden muss. Hier kommen, du ahnst es schon, die OKRs ins Spiel.

Wie das Zusammenspiel zwischen Scrum 2020 und OKR aussieht, beschreibe ich im zweiten Teil dieses Artikels. Du findest ihn hier: https://andreclaassen.de/post/agile-methoden/der-scrum-guide-2020-aus-sicht-von-objectives-key-results-teil-2