Auftakt: Dies ist ein Blog-Beitrag zum Modul “Product Strategy & Discovery” des Bootcamp Product Owner der Digitale Leute School. Am Mittwoch, 27. September 2023, erläuterte dabei Christina Lange das Framework OKR. Mein Anspruch ist es hier NICHT, allumfassend zu berichten, sondern ich möchte ein paar Impulse weitergeben, die mich selbst bewegt haben.
Was ist OKR?
OKR = Objectives & Key Results “ist ein Strategy Execution Tool”
(Christina Lange)
Natürlich ist mir OKR in meiner Praxis immer mal wieder begegnet, tief damit auseinandergesetzt hatte ich mich aber bisher nicht. Umso mehr war ich gespannt, was Christina dazu vermittelt. Und tatsächlich bestätigt sich im Verlauf des dreistündigen Seminars immer wieder, was sie gleich zu Anfang sagte: OKR kann schnell erklärt werden, aber die Praxis ist schwieriger.
Christina verortet OKR zunächst als ein zeitlich mittelfristig orientiertes Bindeglied zwischen der Umsetzung (etwa über SCRUM und Kanban) und der Unternehmensvision:
- Unternehmensvision: Gültigkeit für 1 bis 3 Jahrzehnte
- OKR: 3 bis 6 Monate
- SCRUM: wenige Wochen
Eine Vision sollte an den Bedürfnissen der Kunden ausgerichtet sein, den Mehrwert des Produkts darstellen – und gleichzeitig Orientierung für Entscheidungen darstellen. Oftmals mündet sie in einem Satz, “aber es geht hier nicht um den Satz, sondern um den Weg dahin”, sagt Christina.
In diesem Modul geht es aber vor allem um OKR als eine Produktstrategie, die gerade im agilen Umfeld als Quasi-Standard gilt.
Objectives sind dabei die übergeordneten Ziele; Key Results die Unterziele (NICHT Aufgaben), die am Ende eines Zyklus’ erreicht werden sollen.
Ziele und Grenzen von OKR
Tatsächlich ist OKR stark verbunden mit einem “Measure”, das heißt, die Key Results werden nicht einfach nur definiert, operationalisiert, sondern auch konkret gemessen. OKR “trainiert also unseren Datenmuskel im Kopf”, beschreibt Christina. Die Eigenschaften sind:
- Es sollen möglichst alle auf einen Kurs gebracht werden.
- Es soll ein gemeinsames Verständnis von den Zielen erreicht werden, “Kommunikation ist hier das A und O”.
- Daraus ergibt sich eine höhere Transparenz.
- Es soll ein bisschen besseres Bauchgefühl erzeugt werden, 100-prozentige Sicherheit gibt es auch durch dieses Tool nicht, “das ist aber OK”.
Tatsächlich sehe ich gerade im letzten Punkt eine Gefahr in der Praxis: Einerseits ist es einleuchten, dass die am Anfang eines Zyklus’ definierten Objectives falsch sein können, genauso, wie die daraus gebildeten Key Results trotz korrekter Objectives falsch sein können. Und natürlich kann auch beides falsch sein. In der Praxis, so meine Befürchtung, werden sich die Teams stark an den gemessenen Erfolgen an den Key Results orientieren und sie als wahr annehmen. Wie durchbricht man dann die sich daraus ergebende Zahlengläubigkeit?
Dennoch: Ein großes Problem von (Software-)Entwicklung ist es, dass sie sehr featuregetrieben sind, ohne Daten und ohne Reflexion. Und hier gibt OKR einen guten Impuls, das genauer zu hinterfragen: Werte für das Unternehmen entstehen nur, wenn ein Produkt genutzt wird (“Value in use”) und nicht, wenn laufend neue Features programmiert werden (“product not used is useless”). Letztendlich ist OKR also ein Umgang mit Unsicherheiten, wie er allen agilen Methoden eigen ist, ein Versuch, diese Unsicherheiten durch echte Daten abzubauen.
Aber, und ich finde, das hat Christina auch sehr schön herausgearbeitet: Letztendlich bleiben die Objectives Wetten auf eine potenzielle Zukunft. Diese Wetten kann man auch verlieren! Aber sie sind ein bisschen besser messbar gemacht worden.
Folgende Zielkategorien können mit den Objectives definiert werden:
- Customer Goals
- Business Goals
- Team Goals
Das OKR-Set
Im Rahmen des Seminars haben wir uns auch selbst an einem OKR-Set versucht. Ich werde aber im Nachgang für einen konkreten Business Case das noch einmal für mich konkret durchspielen. Es gibt verschiedene Sets im Web (zum Beispiel auf Mooncamp). Auch hier gilt sicherlich ein Stück weit: Man muss auswählen, was passt und auch anpassen! Grob aufgeteilt stellt sich das Set aber wie folgt dar:
| Objective 1 | ||
| Key Result 1 | Measure 1 | |
| Key Result 2 | Measure 2 | |
| Key Result … | Measure … | |
| Objective 2 | ||
| Key Result 1 | Measure 1 | |
| Key Result 2 | Measure 2 | |
| Key Result … | Measure … |
Und da das doch etwas abstrakt ist, hier auch das Beispiel aus unserer Übung. In diesem Fall war das fiktive Beispiel ein “AirBnB für Camper”, wir waren das Team Enabler, welches sich stark mit HR, Finance, Legal und Insurance auseinandergesetzt hat. Hier der nicht ganz perfekte Versuch:
“Wir begeistern Mieter mit der hohen Sicherheit rund um die Miete eines Campers.”
| Objective 1: Sicherheit für Mieter im Mietvorgang | ||
| Abschluss von zusätzlichen Versicherungsleistungen | Steigerung um 25 Prozent | |
| Wiederkehrende Bucher | Steigerung um 25 Prozent | |
| … | … |
Ich empfinde dieses Beispiel, selbstkritisch, immer noch als sehr abstrakt, “High-Level”, wie es Christina beschrieb. Aber es sind doch auch schon ein paar Learnings eingearbeitet:
- Die Key Results sind keine Aufgaben (Tasks).
- Es gibt den Versuch, diese zu messen. Im Beispiel wirken die Messgrößen aber noch sehr willkürlich. Aber es ist interessant: Vielleicht stellt sich heraus, dass es noch überhaupt kein Wissen über die Basiszahlen gibt? Oder die Basiszahlen an sich nicht sonderlich gut definiert und aussagekräftig sind? Man kommt direkt ins Machen!
Christina gibt mehrere Praxistipps:
- Wenn Objectives über ein “und” verbunden sind, sollten sie besser aufgeteilt werden.
- Die zentrale Fragestellung sollte sein, was in 3 Monaten anders sein sollte
- Es ist sehr gut, sich auch darüber Gedanken zu machen, was man NICHT macht/erreichen will.
- Über verschiedene Abteilungen hinweg koppeln sich die verschiedenen OKR miteinander; das ist der eigentlich Benefit: Teams arbeiten zusammen an den gleichen Zielen.
Der OKR-Zyklus
Christina beschreibt den OKR-Zyklus als “open source” (im Gegensatz zu Scrum, wo es doch auch alles sehr definiert ist). Er ähnelt aber sehr dem SCRUM-Zyklus:
- Planing
- Alignment
- Startschuss
- Check-In
- Review
- Retrospektive
- Kontext
Letzendlich seien die Planing- und Alignment-Phase sehr chaotisch, so Christina. Das Ziel ist es hier, die OKR-Sets zu erstellen. Wichtig dabei:
- outcome-orientiert (und nicht output-orientiert, also featureorientiert). Beispiel: Ein konkretes Gericht im Restaurant ist ein Output, der begeisterte Gas ein Outcome.
- OKR-Sets sollten nicht on top zum Tagesbusiness erstellt werden, sondern mit diesem verheiratet werden.
- Vermeidung von sogenannten lagging indicators, also zum Beispiel Umsatzwachstum als Ziel. Zu lagging und leading indicators hat Tim Herbig auch einen sehr inspirierenden Vortrag auf dem Digitale-Leute-Summit-2021 gehalten.
- 70 Prozent ist das neue 100 Prozent: Christina plädiert dafür, ambitionierte Ziele in OKR zu definieren, dann aber auch nicht darauf zu pochen, dass sie zu 100 Prozent eingehalten werden. Sie warnt davor, diese als Erfolgsgröße zu definieren, sie sollen vor allem inspirieren. “Measure to lean, not to control.” Wir wollen datengetriebener entscheiden.
- Zu viele Key Results pro Objective sind eine Überforderung, manchmal reicht 1, manchmal vielleicht 3.
Als Abschlussfragen sollen wir für uns selbst beantworten:
- Warum passt OKR besonders gut zu produktorientierten Unternehmen?
- Welche Rolle spielen wir als Product Owner im OKR-Prozess?
Für mich ist klar: Ich will mich noch viel intensiver mit OKR beschäftigen, das ist ein interessanter Ansatz.