OKR Podcast #35: Was gilt eigentlich? OKR oder das Scrum-Backlog?

Viele Scrum Teams, die zum ersten Mal mit OKR arbeiten, stehen vor einem ganz praktischen Problem. Was ist denn jetzt der Ort der Wahrheit? Das Scrum-Backlog oder die OKRs? Oder sogar beides?

In diesem Beitrag stelle ich dir zwei Ansätze vor, wie du mit OKRs und dem Scrum-Backlog in einem Szenario der Produktentwicklung umgehen kannst. Beide Ansätze habe ich in der Realität ausprobiert, aber ein Ansatz ist mein Favorit.

Wer hat Vorfahrt? Die OKRs oder das Scrum-Backlog?

Wenn Scrum Teams mit OKR ihre Prozesse verbessern wollen oder sie mit OKRs konfrontiert werden (auch so etwas soll es geben), stehen sie vor einem ganz praktischen Problem. Arbeitet das Scrum Team weiterhin nach dem Scrum-Backlog, oder stehen in einem OKR-Zyklus die OKRs in dem Vordergrund.

Beide Frameworks, Scrum und OKR, reklamieren für sich, dass ihre jeweiligen Artefakte die „entscheidenen“ sind.

So schreibt der Scrum Guide 2020¹:

Das Product Backlog ist … die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird. – Scrum Guide 2020

Und das gilt für alle Backlog-Einträge, egal wie klein oder groß sie sind. So ist auch das Produktziel im Backlog enthalten. Da OKRs in der Kombination mit Scrum nichts anderes sind als kleiner geschnittene Produktziele, gehören sie auch dort hinein.

Der Scrum Guide 2020 schreibt:

Das Produkt‐Ziel beschreibt einen zukünftigen Zustand des Produkts, welches dem Scrum Team als Planungsziel dienen kann. Das Produkt‐Ziel befindet sich im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren, „was“ das Produkt‐Ziel erfüllt.

Aber leider ist das, was ich heute in Scrum Teams sehe, kein Backlog. Es sind endlos lange Featurelisten. Daher werfe ich zuvor einen kritischen Blick auf das Backlog und die OKRs.

Ein nachdenklicher Blick auf das Backlog

Scrum Teams sind es gewohnt, auf Basis eines Backlogs zu arbeiten. In der Praxis ist es so, dass dieses Backlog meistens über Ticket-Systeme verwalten werden (zum Beispiel mit dem J-Produkt). Ticket-Systeme kommen aus dem Incident-Management und haben eine entscheidende Eigenschaft. Ticket-Systeme vergessen nichts. Genau dafür wurden sie geschaffen. Das ist aber für die Arbeit mit Scrum gar nicht so gut, wie es scheint.

Warum kann das bei Scrum ein Problem werden? Scrum beschreibt das Backlog als emergente Liste. Emergent bedeutet, dass sich das Backlog kontinuierlich wandelt und weiterentwickelt, insbesondere bei den Einträgen selbst. Was ich in der Praxis beobachte ist, dass die meisten Backlogs eines tun: sie wachsen stetig. Ich kenne Backlogs, die haben Einträge, die mehrere Jahre alt sind.

Gegen Wachstum ist erst einmal nichts einzuwenden. Wenn das Backlog wächst, ist das ein Hinweis darauf, dass das Produkt mit den Kunden räsoniert. Es gibt Feedback vom Markt. Gut!

Das Problem entsteht erst, wenn das Scrum Team das Backlog mit einer Anforderungsliste verwechselt. Eine Anforderungsliste hat den Anspruch, in ferner Zukunft vollständig abgearbeitet zu werden.

Wenn das Backlog als Anforderungsliste betrachtet wird, befindet sich das Team unbewusst im klassischen Requirements Engineering. Das Team arbeitet “backlog-driven” Features ab. Produktivität und Kappa sind fortan immer wieder wichtige Themen. Das ist nichts anderes, als ein klassischer Wasserfall, denn das große Backlog ist nichts anderes als Big-Upfront-Design.

"Viele Scrum Teams arbeiten im Backlog-Driven-Modus. Sie arbeiten Tickets ab. Das System belohnt schnelles abarbeiten. Die notwendige Kundenwirkung verliert an Bedeutung. "

Klick hier für einen Tweet

Ein nachdenklicher Blick auf OKRs

Auch auf die OKRs möchte ich einen nachdenklichen Blick werfen. OKRs sind ein Instrument zur Strategieumsetzung. Es geht bei OKRs darum, eine große Vision Realität werden zu lassen.

Wenn wir uns im Kontext eines Scrum Teams bewegen und gleichzeitig mit OKRs arbeiten, kann schnell der Eindruck entstehen, dass die OKRs den Scrum-Prozess gar nicht berühren. Die OKRs kommen von “oben” und müssen irgendwie auch noch gemacht werden. Dafür bekommen sie ein paar Einträge im Backlog reserviert. Fertig!

Dem möchte ich eine andere Sicht entgegenstellen. Wenn du mit deinem Team Scrum machst, dann befindest du dich im Kontext einer Produktentwicklung. Deine Vision ist die Produktvision bzw. das Produkt-Ziel. Natürlich muss das Produkt-Ziel mit der Unternehmensvision im Einklang stehen.

OKRs dienen im Kontext von Scrum vornehmlich dazu, die im Produktziel formulierte Produktstrategie zu realisieren.

Die OKRs sind nichts anderes als kleiner geschnittene Produkt-Ziele, die dich im nächsten Zyklus der Product-Vision näher bringen.

Schön André, und was ist jetzt mit den Unternehmens-OKRs von oben? Ignoriere ich die?

Natürlich nicht, du prüfst zunächst, welchen Einfluss die Unternehmens-OKRs auf die Produktvision haben. Das sind wir wieder bei dem emergenten Backlog. Haben die Unternehmens-OKRs Auswirkungen auf das Produkt oder das Produkt-Ziel? Bekommt das Produkt jetzt eine andere Gestalt?

Falls die Unternehmens-OKRs keinen Einfluss auf die Produktentwicklung haben, formuliert ihr dafür ein OKR, das einen Outcome beschreiben, die auf das obere Unternehmens-OKR einzahlt. Das kann beispielsweise eine organisatorische Anpassung sein.

Es bleibt aber dabei: Das Produkt und die Produktstrategie stehen im Vordergrund. Die Unternehmens-OKRs sind “2nd class citizens”.

"OKRs sind ein Tool zur Strategieumsetzung. Das gilt auch für Scrum. Im Kontext zu Scrum dienen OKRs primär zur Umsetzung der Produktstrategie. "

Klick hier für einen Tweet

Ansatz 1: Backlog-First

Wie schon zuvor geschrieben, ist das wichtigste Artefakt in Scrum das Produkt-Backlog. Das Backlog, so der Scrum-Guide, ist eine geordnete und emergente (dynamische) Liste mit allen Einträgen, die ein Produkt erfolgreich macht.

Beim Ansatz Backlog-First bleibt es so. Auch die OKRs kommen, wie die Produktziele ins Backlog. Die OKRs bilden (exakt wie das Produktziel) eine Art Filter. Sie entscheiden, welche Backlog-Einträge vorgezogen und welche Einträge nach hinten gestellt werden.

Gut geschriebene OKRs formulieren ein Outcome. Auf diese Weise werden die Backlog-Einträge priorisiert, die dieses Outcome (also die Wirkung) am stärksten bedienen.

Es gibt bei diesem Ansatz einige Punkte, auf die ich hinweisen möchte:

• In der Praxis wird beim Backlog-First Ansatz vor dem Entwurf der OKRs gerne in das Backlog geschaut. Dabei kann es passieren, dass die OKRs erst erstellt werden, nachdem die Backlog-Einträge gesichtet werden. Das Ergebnis ist das Reverse-Engineering von OKRs aus dem Backlog heraus. Damit verlieren die OKRs an Kraft und Bedeutung, sie werden mit dem Rückspiegel erstellt.
• Da das Backlog weiter im Vordergrund steht, arbeitet das Team weiterhin im Backlog-driven-Modus. Das bedeutet, dass die OKRs für die Arbeit im Team kaum eine Rolle spielen. Im schlimmsten Fall sind die Objectives “Privatsache” des Product Owners. Das Team arbeitet weiterhin Tickets ab.

"Backlog-First bedeutet, dass das Backlog weiter maßgeblich ist. Die OKR sind kleingeschnittene Produktziele und wirken wie eine Art Filter für die nächste Arbeit."

Klick hier für einen Tweet

Ansatz 2: OKR-First

Der zweite Ansatz scheint etwas radikaler. Bei OKR-First definieren ausschließlich die OKRs die Arbeit und sind der Ort der Wahrheit. In diesem Ansatz gibt es das Backlog weiterhin, aber nur als Ideenspeicher²³. Es können im Planning aber auch ganz neue Ideen entstehen, die noch gar nicht im Backlog erfasst sind. Es ist auch nicht so, dass nach der Formulierung der OKRs jetzt alle Backlog-Einträge zugeordnet werden müssen. Die Arbeit für den nächsten Sprint reicht. In diesem Szenario treiben die OKRs die Arbeit. Alles, was die in den OKRs formulierten Kundenwirkungen treibt, ist gut, alles andere kann zunächst außen vor gelassen werden.

Meine Erfahrung zeigt, dass dieser zweite Ansatz wirkungsvoller ist. Die OKRs beschreiben Kundenwirkungen und zur Umsetzung können ganz frische und völlig neue Ideen entwickelt werden. Die Arbeit mit Scrum fühlt sich wieder so an, wie in den ersten Sprints. Das Produkt steht stärker im Vordergrund, das (schnelle) Abarbeiten von Tickets verliert an Bedeutung.

"OKRs-First bedeutet, die OKRs definieren die Arbeit. Das Backlog dient als Ideenspeicher, es können aber auch völlig neue Ideen entwickelt werden."

Klick hier für einen Tweet

Mein Tipp – Probiere beide Ansätze aus

Die meisten Teams starten ohnehin mit einem Backlog. Mein Tipp ist, probiert beide Ansätze aus. Nutzt einen OKR-Zyklus mit dem Backlog-First Ansatz und einem mit dem OKR-First Ansatz. Wertet die Ergebnisse aus und entscheidet, welchen Ansatz ihr beibehalten möchtet.

Zusammenfassung

Ein Problem in der Zusammenführung von OKR & Scrum ist, dass zwei Orte der Wahrheit aufeinandertreffen: das Scrum-Backlog und die OKRs. Beide Frameworks, Scrum und OKR, reklamieren für sich, dass der Ort der Wahrheit in ihren jeweiligen Artefakten liegt. Es funktioniert nicht, beide Systeme parallel laufen zu lassen. Es ist wie beim Highlander, es kann nur einen geben.

Daher empfehle ich, eine Entscheidung zu treffen: Entweder nutzt ihr den Backlog-First oder den OKR-First Ansatz. Meine eigene, für mich selbst überraschende Erfahrung, ist es, dass der OKR-First Ansatz die stärkste positive Wirkung auf das Scrum Team erfüllt. Dennoch sind beide Verfahren zur Arbeit mit OKR und Scrum geeignet.

Einmaliges Angebot: OKR meets Scrum

Wenn du die Arbeit mit OKR & Scrum selbst erleben willst, empfehle ich dir das Angebot der Agilizer-Academy⁴ anzuschauen. In zwei Tagen lernst du ganz praktisch, wie beide Ansätze ideal zusammenspielen. Referenzen