OKR Podcast #30: OKR & Scrum kombinieren? Warum sollte das jemand tun?

OKR & Scrum kombinieren? Warum sollte das jemand tun?

Immer mehr Organisationen nutzen das Frameworks Objectives & Key Results (OKR). Und oft trifft OKR dabei auf Scrum, ein leichtgewichtiges Framework zur Lösung von Problemen in komplexen Umfeldern. Jetzt entstehen schnell eine Reihe von Fragen. Die wichtigste Frage ist vielleicht, warum sollte Scrum überhaupt mit OKR kombiniert werden? Warum sollte das jemand tun?

Bevor ich meine Antwort auf diese Frage gebe, werfe ich einen kurzen Blick auf den Kern von OKR & Scrum.

Zwei Frameworks, zwei Flughöhen

Für Organisationsmodelle nutze ich gerne das Bild der Flughöhen (Flight Levels) von Klaus Leopold1. Leopold sagt, dass es drei Flughöhen gibt, in denen die Zusammenarbeit und Wertschöpfung von Organisationen betrachtet werden kann:

  • Flightlevel 3: Die strategische Flughöhe auf Unternehmensebene
  • Flightlevel 2: Die koordinierende Flughöhe zwischen Teams
  • Flightlevel 1: Die operationalisierende Flughöhe innerhalb von Teams

Zwei Frameworks, zwei Flughöhen

Wie lassen sich die beiden Frameworks OKR & Scrum hier einordnen?

  1. OKR ist ein Framework zur Strategieumsetzung. Es dient dazu, dass Menschen in einer Organisation gemeinsam an großartigen Initiativen arbeiten. OKR ist zudem ein Denkwerkzeug, für mehr wirkungsorientierte und selbstorganisierte Arbeit im Unternehmenskontext. So gesehen ordnet sich das Framework OKR auf Flightlevel 3 (strategisch) und Flightlevel 2 (koordinierend) ein.
  2. Scrum ermöglicht es Teams, in komplexen Umfeldern adaptive Lösungen zu entwickeln. Scrum findet sich oft auf der Umsetzungsebene Flightlevel 1, also auf Teamebene wieder.

Scrum & OKR agieren auf unterschiedlichen Flughöhen der Wertschöpfung. Damit steht einer prinzipiellen Kombination nichts im Wege. Wenn das schöne Wort „Warum“ nicht wäre.

Was bringt OKR auf den Tisch?

Oft wird OKR als Managementsystem für Ziele bezeichnet. Und damit wird es in einen Topf mit dem klassischen “Management by Objectives” oder dem Performancemanagement geworfen. Das ist leider ein gefährlicher Mythos. Denn in Wirklichkeit geht es bei OKR gar nicht so sehr um die Zielerreichung, es geht um Wertschöpfung.

Das wird von Allan Kelly von Software Strategy Ltd. gut den Punkt gebracht[^5]:

OKRs are not about measuring progress towards a goal or ticking off work items on a manifest. OKRs are about delivering outcomes that add value — Allan Kelly

OKRs are about delivering outcomes, that add value by Allan Kelly

Es geht bei OKR um die Lieferung von Outcomes, die eine Wertschöpfung darstellen. Die Frage ist nur, was genau ist denn so ein Outcome?

Was ist ein Outcome?

Aber was ist eigentlich so ein Outcome? Im Deutschen gibt es keine einfache Übersetzung. Ein Outcome ist schlicht ein Arbeitsergebnis. Ich sage, ein Outcome ist ein Arbeitsergebnis, das eine gewünschte Wirkung entfaltet.

Bei Outcomes gefällt mir die Definition von Joshua Seiden2 am besten.

Outcomes sind Veränderungen im Verhalten von Kunden, Nutzern, Mitarbeitern, die zu guten Dingen führen — Josh Seiden

Outcomes sind Verhaltensänderungen von Josh Seiden

Was Joshua meint ist, dass die Umsetzung von Features, Epics und Stories erst Früchte trägt, wenn diese zu einer nützlichen Verhaltensänderung bei einer definierten Zielgruppe führen. Und der Nutzen darf auch gerne dem Unternehmen selbst zu Gute kommen.

Hier sind ein paar Beispiele, die den Unterschied zwischen Output (Arbeitsergebnissen) und Outcome (Wirkungsergebnissen) veranschaulichen.

Outcome Output
Unsere Kunden stellen 15% weniger Anfragen für Umgehungslösungen beim Support. Wir bereinigen 50 Bugs
Die Kunden lieben das neue Onboarding und brechen den Vorgang um 20% seltener ab. Wir implementieren einen neuen Onboarding Prozess
Unsere Buchhaltung freut sich, weil das Saldo von Fehlbuchen auf von 15.000€ auf 500€ gesunken ist. Wir müssen die 10 wichtigsten Fehler im Zahlungsverkehr bereinigen

OKR & Scrum = Erleichterung durch Fokus

Eine der zentralen Ideen von Scrum ist es, die gesamte Arbeit in einem Backlog zu organisieren. Alle Ideen, alle Arbeit, alles kommt in ein einziges Backlog und ist erst einmal aus dem Kopf. Jetzt muss das Backlog nur noch priorisiert werden und die Arbeit kann beginnen. So die Idee von Scrum3.

Das klingt zunächst gut. Das macht den Kopf frei.

Und zugleich entsteht schleichend ein Problem. Das Backlog wächst, wird größer und wird irgendwann in einem Ticket-System verwaltet. Die Beschäftigung mit dem Backlog und den Tickets nimmt einen immer größeren Raum ein. Kunde und Wirkung beginnen zu verblassen.

Im Lean-Kontext nennen wir das Kind beim Namen: Ein großes Backlog ist Waste, also Verschwendung.

Hier kommt OKR ins Spiel:

  • Wie wäre es, wenn wir jetzt mal wirklich den Kopf frei machen?
  • Wie wäre es, wenn wir uns gemeinsam im Team überlegen, welche Produktziele wir in den nächsten 90 Tagen verfolgen und welche Themen zunächst konsequent zurückgestellt werden?

Und wie schön wäre es, wenn die Diskussion dabei nicht über Features, sondern über Wirkungen beim Kunden geführt würde?

Langsam löst sich das Team aus dem Hamsterrad der Tickets. Alle 3–4 Monate wird im Supersprint geplant, welche größeren Themen und Outcomes erreicht werden sollen. Das sind die neuen Produktziele aus Scrum und diese werden als Objectives & Key Results formuliert.

Jetzt, wo die wesentlichen Produktziele klar sind, kann im Team überlegt werden, welche Initiativen die Produktziele treiben und welche nicht4. Idealerweise startet ihr den Supersprint sogar mit einem leeren Backlog. Das meine ich Ernst. Ihr startet den Supersprint mit einem leeren Backlog. Das alte Backlog kann gerne als Ideenspeicher und Archiv verwendet werden.

Ich nenne das Outcome Based Planning. Und wenn du jetzt nicht genug von dem Thema hast, oder einfach noch unsicher bist, schau dir dieses Video von C. Todd Lombardo an. Übrigens, er spricht er nicht einmal von OKR, sondern ganz viel von Roadmaps. Gemeint ist aber exakt das Gleiche!

Kurz zusammengefasst

OKR rettet Scrum-Teams davor, zu einer Art „Ticket-Factory“ zu werden. OKR hebt den Blick auf das, worum es in der Produktentwicklung wirklich geht: Kundennutzen. Mit OKR formuliert ihr in einem Supersprint 1-4 Produktziele, die messbare Outcomes beschreiben. Dadurch schafft ihr einen Fokus auf die Nutzer eurer Arbeit, und klärt das gewünschte nützliche Verhalten. Die Priorisierung von Backlogs vereinfacht sich durch die Existenz fokussierter Produktziele dramatisch. Eine Frage bleibt offen, die ich gerne in der nächsten Woche beantworten will: „Dear OKR, where’s my business Agility?“ Also kurz: Zerstört OKR die Agilität und die Freiräume von Scrum? Eine gute Frage, im nächsten Artikel gebe ich eine Antwort.

Photo by Ashkan Forouzani on Unsplash

[^5] Ich kann sehr das Buch von Allan Kelly zu dem Thema Agile & OKR empfehlen: https://leanpub.com/agileokrs


  1. Siehe zum Beispiel hier: https://www.agile-academy.com/en/organizational-development/flight-levels-in-action-klaus-leopold/ ↩︎

  2. Joshua hat ein ganzes Buch zu dem Thema geschrieben. Es ist kurz und auf den Punkt geschrieben und wirklich lesenswert. ↩︎

  3. Und diese Idee hat Scrum von David Allen mit „Getting Things Done“ übernommen. ↩︎

  4. Übrigens kann eine solche Planung mit OKR hervorragend genutzt werden, um gemeinsame Produktziele über mehrere Scrum-Teams hinweg zu entwickeln. Dadurch entsteht eine völlig neue Art der Synchronisation. ↩︎

Previous PostOKR Podcast #29: Mehr Wirkung bitte! Ein Gespräch mit Natalija Hellesoe über OKR im Wandel der Zeit
Next PostOKR Podcast #31: Verhindern OKRs agile Arbeit?
comments powered by Disqus