Am 18. November 2020 feierte scrum.org das Release des neuen Scrum Guides. Wirklich Neues gibt es nicht… bis auf das Produktziel („Product Goal“). Denn dieses Element fordert den Fokus des Scrum Teams auf exakt ein Ziel. Geht das überhaupt? Wie passt das in die Realität von Unternehmen?
Bevor ich auf diese Veränderungen eingehe, erlaube ich mir einen Schnelldurchlauf durch die Artefakte von Scrum, zu denen auch das bereits erwähnte Product Goal zählt.
Scrum Artefakte
In Scrum gibt es drei Artefakte:
- das „Product Backlog“,
- das „Sprint Backlog“ und
- das „Increment“
Während Product und Sprint Backlog die Arbeit am Produkt sichtbar machen, ist das Increment das vollständige Ergebnis der Arbeit der letzten Iteration („Sprint“).
Commitments
Außerdem gibt es sogenannte „Commitments“, die an die Artefakte gebunden sind. Leider sind die Commitments im Scrum Guide ein wenig verschwurbelt beschrieben: sie stellen weitere Informationen zur Verfügung, um die Transparenz und den Fokus zu erhöhen. Sie verstärken den empirischen Ansatz und die Scrum-Werte für das Team und die Stakeholder ([1], S. 10).
Das neueste Commitment ist das „Product Goal“, das die bereits vorhandenen Elemente „Sprint Goal“ und die „Definition of Done“ ergänzt.
Definition of Done
Die „Definition of Done“ entspricht einer transparenten Checkliste aller Qualitätsmerkmale, die erfüllt sein müssen, damit die Arbeit am „Increment“ als „fertig“ gelten kann ([1], S. 12).
Sprint Goal
Das „Sprint Goal“ ist das eine kurzfristige Ziel („Objective“), das mit einem Sprint erreicht werden soll. Es dient dem Fokus, an dem die Mitarbeitenden des Scrum Teams sich ausrichten können ([1], S. 11).
Neu: Product Goal
Das „Product Goal“ wird mit dem Scrum Guide 2020 eingeführt, um das eine langfristige Ziel („Objective“) zu definieren, das das Produkt in Zukunft erreichen soll. Es legt den Fokus auf eine Eigenschaft, die das Produkt oder die Dienstleistung noch wertvoller für die Kund*innen macht.
Das langfristige Ziel ist insofern eine Herausforderung, da es sich nicht jeden Tag und nur in Details ändern sollte. Ein sorgloser Umgang führt dazu, dass der Fokus verloren geht und die Aufwände zur Anpassung teuer werden. Der Scrum Guide gibt außerdem vor, das immer nur exakt ein Sprint Goal bearbeitet und vervollständigt wird, bevor das nächste an die Reihe kommt ([1], S. 11).
Mehr Fokus, mehr Mut
Es gibt nur ein Product Goal? Welche Organisation hat nur ein Ziel? Die Menschen, die diese Ziele festgelegt haben, haben gute Gründe, warum diese jetzt verfolgt werden sollten. Dann macht es doch Sinn, an allen zu arbeiten… oder?
Auf Unternehmensebene kann diese Aussage zurecht in Frage gestellt werden. Für Teams, die an einem Produkt arbeiten – und diese fokussiert der Scrum Guide – gilt dies bewiesenermaßen nicht. Auch wenn es mehrere Produktverbesserungen geben kann, so verfolgt Scrum den Ansatz schnell auf den Markt zu reagieren und Feedback vom Markt zu erhalten.
Wenn an mehreren Verbesserungen zeitgleich gearbeitet wird, verzögert sich die Veröffentlichung aller bearbeiteten Themen (vgl. Little’s Law, [4]). Die Feedbackzyklen werden länger, und das Risiko steigt, dass sich das Produkt am Markt vorbeientwickelt. Um dies zu verhindern, fokussiert das Scrum Team exakt ein Product Goal.
Product Goal (langfristiges Ziel) und Sprint Goal (kurzfristiges Ziel) geben also einen Rahmen, der das Scrum Team dazu ermutigt, die Themen, die diese Ziele NICHT unterstützen, zu verschieben oder gar nicht umzusetzen. Kurz: das Team wird ermutigt, „Nein“ zu sagen.
Mut im Unternehmen
Leider gibt es im Scrum Guide bis heute keine direkten Empfehlungen, wie die Führungskräfte mit Themen umgehen können, die nicht zum Fokus passen, aber dennoch akut umgesetzt werden müssen.
Das Product Goal verschärft damit den Druck auf das Unternehmen. Denn die klassischen Mechanismen der Steuerung durch Absprachen auf der Führungsebene sind durch die folgenden Scrum-Vorgaben ausgehebelt:
- als externe Führungskraft sollten Sie neben den etablierten Wegen keine weitere Aufträge an die Mitglieder eines Scrum Teams geben.
- der Product Owner ist als einziger autorisiert, das Product Backlog zu ändern.
Tatsächlich gibt es mehrere Optionen, die sich für Führungskräfte im Scrum-Umfeld ergeben:
- Überzeugungsarbeit auf Augenhöhe: Product Owner sollten zur Verfügung stehen, um Einwände zu diskutieren. Wichtig ist eine ergebnisoffene Herangehensweise (d.h. das Scrum Team könnte Recht haben).
- das Product Goal ist nicht in Stein gemeißelt, das heißt, es kann angepasst werden, wenn es in die falsche Richtung weist. Hier sind sowohl der Product Owner als auch andere Stakeholder gefragt, in eine offene Diskussion zu gehen.
- Wenn Themen in der Organisation hängen bleiben, dann funktioniert die Organisation nicht gut genug. Welche Potenziale kann das Unternehmen nutzen, um derartige Aufgaben zu lösen? Gibt es andere Wege, derartige Themen dauerhaft zu lösen oder zu vermeiden (Strategien)?
Kein Unternehmen kann alle offenen Themen bearbeiten. Es ist viel Mut erforderlich, eigene notwendige Projekte hinten anzustellen. Gerade dann, wenn an Zielen auch Incentives gebunden sind, stellt sich schnell die Frage, warum eine bestimmte Führungskraft nun auf den Bonus verzichten sollte.
Das Product Goal zerrt solche Fragen in den Fokus. Es kostet viel Mut, Ausdauer und Ehrlichkeit, die Organisation beispielsweise zum Verzicht auf bestimmte Incentiveregelungen zu bewegen, damit das Scrum Team (wieder) sauber arbeiten kann.
Zusammenfassung
Das Product Goal ist meines Erachtens die wichtigste Änderung des Scrum Guides. Konsequent umgesetzt führt es zur Findung klarer Entscheidungen, was umgesetzt wird und was nicht.
Scrum löst keine Probleme, es macht sie nur sichtbar. Das „Nein“ eines Scrum Teams löst zwangsläufig ein Dilemma in Unternehmen aus, das nicht auf die leichte Schulter genommen werden sollte. Denn natürlich kann die Führungskraft mit einer Anweisung das Problem schnell aus der Welt schaffen. Da das Scrum Team aber dann nicht mehr selbstverwaltet arbeitet, wird es schnell dysfunktional.
Die Alternative – nämlich das „Nein“ als Anlass für Veränderungen in der Organisation zu verstehen – kann ebenfalls schwierig werden, wenn es eine geringe Akzeptanz für Veränderungen im Unternehmen gibt.
Das alles ist nicht wirklich neu. Das Product Goal schärft damit noch einmal den Blick auf die Organisation. Welche Ziele sind wirklich wichtig? Und was muss die Organisation tun, damit Scrum Teams gut arbeiten können? Was bedeuten die Veränderungen für das Management? Schneller als das Unternehmen vielleicht will, beginnt die Umstellung. Willkommen in der Transition des Unternehmens!
Updates
Im Abschnitt „Mehr Mut, mehr Fokus“ stand versehentlich „Es gibt nur ein Sprint Goal? …“. Es muss natürlich „Es gibt nur ein Product Goal? …“ heißen. Korrigiert am 8.12.2020.
Quellen
- Schwaber Ken, Sutherland Jeff. The Scrum Guide. The Definitive Guide to Scrum: the Rules of the Game. November 2020. scrumguides.org, PDF in der US-Fassung – zuletzt überprüft am 07.12.2020
- Scrum Guide 2020: Mehr Klarheit für die Organisation – Blog Post vom 30.11.2020
- Manifest für Agile Softwareentwicklung. agilemanifesto.org – zuletzt überprüft am 07.12.2020
- Vacanti, Daniel: Little’s Law for Professional Scrum with Kanban. Scrum.org, 05/2018 – zuletzt überprüft am 07.12.2020