Wie man Objectives & Key Results (OKR) erfolgreich in den agilen Produkt-Alltag integriert

Objectives & Key Results – kurz OKR – sind ein wirksames Mittel, um mit klaren Zielen (Produkt-)Teams Autonomie zu ermöglichen und gleichzeitig den unternehmensweiten Fokus auf das Wesentliche zu legen. Auch wenn es keine allgemein gültige Anleitung für die Nutzung von OKR gibt, so sind einige Tipps dabei hilfreich, das volle Potenzial der Methode zu erleben.

Häufig entstehen jedoch Vorbehalte gegenüber einer weiteren “Prozessschicht” wie OKR – gerade bei agil arbeitenden Teams. Fragen wie: “Wie verhalten sich OKR und Epics zueinander?”, “Was sind die Auswirkungen von OKR auf meine Produkt-Roadmap?”, “Wie kann ich OKR in meine bestehenden Scrum-Routinen integrieren?”, oder “Was sind eigentlich gute OKR für Produktmanager?” sind nur einige Beispiele aus der Praxis, die schnell folgen.

In diesem Artikel möchten wir daher einen genaueren Blick auf den effektiven Einsatz von OKR in agilen Produkt-Umgebungen werfen und so Klarheit über die Verbindungen, möglichen Mehrwerte oder Dopplungen zu bestehenden Arbeitsweisen schaffen.

Was sind OKR?

OKR steht für Objectives & Key Results. Kurz gesagt, OKR verbindet die besten Aspekte guter Ziele in einem anfassbaren Framework: Eine sehr inspirierende qualitative Beschreibung der nächsten Etappe kombiniert mit präzisen und messbaren Kennzahlen, um Erfolg oder Misserfolg von Beginn an klar und eindeutig für alle zu bestimmen.

Objectives

Objectives funktionieren wie ein Leitbild, nur für einen kürzeren Zeitraum. Es beschreibt den nächsten Schritt hin zur Erreichung der Vision, inspiriert das Team, ist schwer (aber nicht unmöglich) in einem festgelegten Zeitrahmen zu erreichen und kann von der Person oder den Personen, die es festgelegt haben, selbstständig erreicht werden.

Bei der Formulierung eines Objectives solltet ihr auf diese 4 Attribute achten:

1. Qualitativ, ambitioniert und inspirierend
2. Bringt alle einen Schritt näher zu Strategie / Vision / Purpose
3. Zeitgebunden
4. Möglichst unabhängig erreichbar vom jeweiligen Team

Angenommen ein B2B SaaS-Startup namens “Analytico” hat aus seiner aktuellsten Strategieanalyse und den vergangen Quartalen abgeleitet, dass sie ihre Reichweite und Wirksamkeit durch eine neue Nutzergruppe erweitern wollen. Dies könnte in folgendes Objective münden:

Neues Kundensegment Online-Marketers erobern

Ob dieses Ziel tatsächlich ambitioniert, inspirierend und passend für den Zeitraum (zum Beispiel des nächsten Quartals) ist, kann nur vom Analytico-Team beurteilt werden, weil es das Ergebnis ihrer gemeinsamen Diskussionen widerspiegelt.

Das Objective allein würde jedoch einen großen Interpretationsspielraum offen lassen, was eigentlich ganz genau mit der Expansion hin zum Online-Marketing  gemeint ist. Es besteht die Gefahr, dass unterschiedliche Personen und Teams der Organisation dies unterschiedlich auslegen und vielleicht in entgegengesetzte Richtungen zu arbeiten.

Key Results

Der Ziel-Zustand des Produktes oder der Organisation am Ende des Zyklus wird dann durch die dazugehörigen Key Results konkret quantifiziert. Simple Fragen, um Key Results zu definieren sind etwa: “Woher weiß ich, wenn ich mein Objective erreicht habe?” oder “Welche Zahlen würden sich dadurch ändern?”.

Mit in der Regel 2-5 Key Results wird das Ziel aus verschiedenen Perspektiven spezifiziert und greifbar. Wäre das erreichte Ziel am Quartalsende eine Tasse, so würden die Key Results diese Tasse, diesen ambitionierten Zielzustand, aus den verschiedenen Blickwinkeln von oben, unten, rechts und links beschreiben. Mit diesem Ansatz vermeidet ihr einseitige Scheuklappen bei eurer Ziel-Beschreibung.

Key Results können dabei relative oder absolute Zahlen sein, oder auch Meilensteine. Binäre Ja/Nein-Beschreibungen sind auch möglich, sollten keine passenden Kennzahlen vorhanden sein. Verschiedene Perspektiven können zum Beispiel durch Metriken rund um Umsatz, Produktqualität, Anzahl Nutzer, Wachstum oder Performance-Aspekte beschrieben werden.

Passend zu unserem oben genannten Beispiel, könnte Analytico sein Objective mit folgende Key Results spezifizieren:

• KR 1: 100.000 Leads von Online-Marketers im Akquise-Funnel
• KR 2: 50.000 Euro Umsatz aus neuem Segment
• KR 3: Von 50 auf 80% Kundenzufriedenheitsrate in Zielgruppe
• KR 4: 4 neue Produkte für Zielgruppe

In unserem Beispiel haben wir Wert darauf gelegt, auch Aspekte, die über Performance hinausgehen, zu berücksichtigen. Die Key Results enthalten bewusst keine konkreten Features oder Lösungen, sondern geben dem Team die Freiheit, selber die effektivsten Lösungen zu discovern, um Umsatz und Zufriedenheit zu steigern. Die Anzahl der neuen Produkte stellt lediglich eine Orientierung dar, dass es herausfordernd wäre, nicht nur ein neues zusätzliches Produkt, aber auch nicht 40 neue Produkte zu konzipieren.

Schließlich sind alle drei Metriken auch kontinuierlich entlang des Zyklus messbar. z.B. mit mehreren Umfragen über das Quartal hinweg.

OKR Zyklus

Wichtige Elemente zum erfolgreichen Arbeiten mit OKR sind außerdem das regelmäßige Messen und Besprechen des Fortschritts im wöchentlichen oder zweiwöchentlichen “OKR Check-Ins” sowie eine “OKR Reflexion” der erreichten Ergebnisse und der Zusammenarbeit hin zur Zielerreichung während dieser Zeit.

Der “OKR-Check-In” ermöglicht, jederzeit die konkreten Aufgaben oder Projekte schnell anzupassen, sollte sich der erwünschte Fortschritt nicht einstellen, statt dies erst nach dem abgelaufenen Quartal zu betrachten.

Zu einem effizienten OKR Check-In gehören drei Bestandteile:

1. Der Blick zurück: Was haben unsere Aktivitäten bis jetzt für die Zielerreichung gebracht?
2. Der Blick nach vorn: Wie sicher sind wir, dass wir unser Ziel zu 100% erreichen?
3. Konkrete Planung: Was sind die Prioritäten in dieser Woche, um den nächsten, größtmöglichen Schritt in der Zielerreichung zu machen?

Die abgebildeten “Hygiene”-Faktoren oder “Health Metrics sind übrigens eine einfache Möglichkeit, Fokus-Themen aus vorhergehenden Quartalen weiterhin zu messen. Nur weniger granular und eher grob mit rot/gelb/grün bewertet.

Die “OKR Reflexion” am Quartalsende blickt sowohl auf den letzten Stand der Zielerreichung, aber auch gibt auch Raum, die grundsätzlich Zusammenarbeit hin zur Zielerreichung sicherzustellen. Sie ist die Grundlage für gemeinsames Lernen in Bezug auf Ziele, OKR und alle damit verbundenen Themen, die Ziele beeinflusst haben.

Erfolgreicher Ziele erreichen mit OKR

Die “Erfindung” der OKR wird häufig Andy Grove während seiner Zeit bei Intel zugeschrieben. Die heutige Popularität rührt allerdings von der Verbreitung im Silicon Valley durch den Venture Capitalist John Doerr. Während die performance-orientierte Nutzung von OKR bei Google oft als “Blueprint” gesehen wird, lässt sich durch die individuelle Einführung in eurer Organisation noch viel mehr damit erreichen.

Aus der Vogelperspektive können Objectives & Key Results Organisationen und deren Produkt-Teams dabei helfen, drei ihrer Kernfähigkeiten zu verbessern:

1. Mehr Fokus auf die wirklich wichtigen Initiativen
2. Besseres Alignment zwischen Teammitgliedern und Teams
3. Mehr Autonomie bei der Definition von Lösungen

Aber was heißt das eigentlich?

1. Mehr Fokus

Ein “typischer” Zyklus für OKR geht über ein Quartal. Einige Unternehmen arbeiten auch zusätzlich mit jährlichen OKR, um Teams auch über die nächsten drei Monate hinaus Orientierung zu geben. Grundsätzlich kann der Zyklus ganz individuell bestimmt werden, passend zu den Rhythmen der Organisation.

Je Ebene der Organisation werden maximal drei OKR definiert. Dies soll sicherstellen, dass sich alle auf wenige Initiativen fokussieren, diese dann aber auch tatsächlich wahrscheinlicher erfolgreich abgeschlossen werden.  Mit klarem Fokus ist gleichzeitig auch immer eine De-Priorisierung verbunden.

Während einige Stakeholder “Agile” damit verwechseln, ihre Meinung alle zwei Wochen gerade rechtzeitig für die Sprint-Planung zu ändern, bereiten OKR einen kontinuierlichen Weg für das ganze Quartal und die gesamte Organisation, auf den sich das Produkt-Team dann fokussieren kann.

OKR haben nicht den Anspruch, die komplette Aufgabenplanung eines Teams vorab zu “regeln”. Sie geben vielmehr eine Orientierung, in welche Richtung es gehen soll, was erreicht werden soll.

Die konkrete Feature und Sprint-Planung erfolgt weiterhin an bekannter Ort und Stelle. Erarbeitete Entwicklungen im Sprint sollten dann darauf einzahlen, dass ein OKR erfüllt wird.

Im besten Fall umfassen die OKR fast alle Themen, die im Team stattfinden. Jede*r Produktmanager*in weiß natürlich, dass kritische Bugfixes oder Wartungsarbeiten jederzeit auftreten können. Dafür könnte man beispielsweise von Anfang an eine gewisse Ressourcen-Kapazität für Wartung mit einplanen.

Auch werden im Laufe eines OKR-Zyklus immer neue Themen aufkommen, die man zu Beginn noch nicht kannte. Diese gilt es dann nicht einfach blind liegen zu lassen “weil sie ja nicht in den OKR stehen”, sondern zumindest gemeinsam darüber zu sprechen, ob die ursprünglich definierten Prioritäten trotzdem verfolgt werden oder ganz bewusst eines der OKR nun ersetzt werden soll.

2. Mehr Alignment

Wenn OKR im gesamten Unternehmen genutzt wird, werden alle Ebenen und Bereiche, für die OKR erstellt werden von Beginn an oder bei der Kaskadierung einbezogen.

Das Abgleichen und Synchronisieren aller OKR zu Quartalsbeginn, dem sogenannten Alignment, ermöglicht es in der restlichen Zeit des anstehenden Quartals gemeinsam und fokussiert an denselben Zielen arbeiten.

Alle Ziele des Unternehmens, der Bereiche und der Teams werden transparent für alle festgehalten. Das gilt auch für den zwischenzeitlichen Fortschritt aus den OKR-Checkins und die finale OKR Reflexion.

Auch diese Transparenz ermöglicht Klarheit und Alignment über die Arbeit in anderen Bereichen und Teams.

3. Mehr Autonomie

Um Selbstverantwortung für Teams und Personen bei der Gestaltung ihrer Aufgaben zu ermöglichen, ist die Klarheit von Zielen eine wichtige Grundvoraussetzung. Autonomie entsteht jedoch nicht automatisch mit der Nutzung von OKR als Ziel-System. Es ist eine bewusste Entscheidung für die Kultur der Zusammenarbeit nötig, an welchen Stellen von Strategie zu Zielen zu Aufgaben Autonomie gewollt und unterstützt wird. Je nachdem würde man das eigene OKR-System auch unterschiedlich leben.

Sind die OKR eher output-orientiert formuliert, werden konkrete Ergebnisse, Teilaufgaben und Meilensteine bereits für das gesamte Quartal vorgedacht und weder Agilität noch Autonomie werden ermöglicht. Zum Beispiel:

Objective: Neues MVP ist live

• Key Result 1: Feature 1, 2, 3 sind live
• Key Result 2: Feature 3, 4, 5 sind beschrieben
• Key Result 3: 10 Nutzertest haben stattgefunden

Sind die OKR hingegen eher outcome-orientiert formuliert, lassen sie den Teams die Freiheit der Entscheidung, über welche Wege das Ziel erreicht werden soll. Das erfordert das Distanzieren von Feature-Wishlists mit Deadlines und unterstützt die Diskussion zwischen Teams und Stakeholdern welche tatsächliche Wirkung Initiativen bezwecken sollen.

Ein OKR würde dann zum Beispiel besser so formuliert werden:

Objective: Lernen von überall möglich

• Key Result 1: Von 0 auf 80% mobile Nutzeranteil
• Key Result 2: Alle (Anzahl X) Funktionen sind von unterwegs erreichbar
• Key Result 3: 60% Nutzerzufriedenheit von mobile Nutzern

Durch die Nutzung von OKR könnten Mitarbeiter*innen nicht nur mehr Autonomie für ihre Aufgaben erhalten, sondern auch selbstbestimmt ihre eigenen Ziele definieren. Das ist davon abhängig, wie das eigene OKR System aufgesetzt ist und ob Ziele von Unternehmensebene herunter bis auf Teamebene kaskadiert werden, oder andersherum die Teams zunächst Ziele festlegen und die Unternehmens-Ziele ergeben nur noch die Zusammenfassung dieser.

OKR und agiles Produktmanagement kombinieren

Typischerweise lässt sich jedes Artefakt der agilen Prozessen in einer Organisation in das bucket WHY, WHAT oder HOW einsortieren.

Purpose, Mission, Vision oder Aspekte der Strategie einer Organisation beschreiben das langfristige WHY. Da OKR den nächsten Schritt hin zur Erreichung der Vision beschreiben, können sie als eine Art Mini-Vision für das Quartal verstanden werden und sind ebenfalls dem WHY zuzuordnen, aber in Bezug auf einen kürzeren Zeithorizont.

Die agile Product Discovery und Delivery hingegen fokussiert sich größtenteils auf das WHAT. Welche Themen, Features, Technologien werden umgesetzt, um das WHY der Organisation zu erreichen. Je nach Artefakt haben sie einen mittleren bis kurzfristigen Zeithorizont.

Wie in dieser Gegenüberstellung sichtbar wird, ersetzen OKR keine der vorhanden Product Execution Prozesse. Vielmehr sind sie eine Ergänzung oder greifbare Beschreibung des großen WHY, dass so hilft einfach im Alltag zu priorisieren, welche der vorhandenen Ideen und Themen tatsächlich umgesetzt werden sollten, oder zu reflektieren, ob sie den gewünschten Erfolg bewirkt haben.

Das Erreichen von Zielen mit OKR hängt zu großen Teilen davon ab, wie man die formulierten Ziele im Anschluss in die alltäglichen Arbeitsprozesse integriert.

Da Unternehmen OKR auf unterschiedliche Weise benutzen und auch Arbeit zum Beispiel in Produkt-Teams je nach Methode und Anpassungen mit Scrum, Kanban und Co. individuell organisiert wird, gibt es keine allgemein gültigen Regeln für diese Verzahnung.

Ein Tipp wäre jedoch, OKR in grundsätzlich alle Entscheidungsprozesse während der einzelnen Phasen in Planning, Discovery und Delivery sichtbar zu machen und als Priorisierungs-Instrument zu benutzen

OKR in den Product Roadmap- und Planungsprozess integrieren

OKR und Themes/Epics haben einen ähnlich mittelfristigen Zeithorizont. Vorhandene Themes/Epics oder eine bestehende Roadmap können neben Vision und Erfahrungen der letzten Quartale einige der Quellen sein, um die OKR fürs kommende Quartal zu erarbeiten.

Stehen die Ziele mit den neuen OKR fest, ist es jedoch wichtig, den Pool an Ideen aus Roadmap/Themes/Epics entsprechend neu zu sortieren, so dass nur noch Themes/Epics bearbeitet werden, die tatsächlich auf das aktuelle OKR einzahlen. Eventuell müssen sogar neue Themes/Epics erstellt werden, sollte es keine passenden geben.

Analog zu einem klassischen Sprint Planning I und II, erfolgt nach der OKR-Definition dann ein gemeinsamer Task Breakdown, in dem diskutiert wird, welchen Initiativen nachgegangen wird, um die OKR zu erreichen (siehe Abschnitt OKR in Product Delivery integrieren).

In vielen Firmen findet der Planungsprozess in der Produktentwicklungen noch mit zeitbasierten Feature-Roadmaps in Form von Gantt-Charts statt. Diese Limitierung auf vordefinierte Lösungen (und “vorhergesagte” Zeiträume) nimmt den Teams jedoch die Flexibilität, wirkungsorientiert zu arbeiten und selber die bestmögliche Lösung zu discovern und umzusetzen. Deshalb stoßen Feature-Roadmaps und outcome-orientierte OKR schnell an die Grenzen ihrer Kompatibilität.

Abhilfe kann das Konzept der “Theme-based Roadmaps” schaffen. Der Unterschied zur klassischen, zeitbasierten Roadmap liegt in der Detailtiefe. Je näher ein Thema auf der Roadmap rückt, umso detaillierter ist dieses bereits bekannt und beschrieben. Je weiter weg ein Thema ist, desto unkonkreter ist es beschrieben und erfährt nur eine zeitliche Einordnung in die groben Kategorien “bald” und “später”.

Zu den groben Überschriften der Themes gesellen sich, je nach zeitlicher Entfernung, dann konkrete Unterpunkte als Epics (typischerweise das Ergebnis einer Product Discovery).

Neue Ideen für eine der Spalten lassen sich somit dann entweder durch Quartals-OKR (NOW) oder Jahresziele bewerten und priorisieren. Ohne die spezifische Festlegung auf Features im Voraus haben Teams die Flexibilität, die effektive Lösung für ein Theme zu entwickeln.

OKR in Product Discovery integrieren

Während die Zyklen für die tatsächliche Entwicklung eines Produkts durch Frameworks wie Scrum & Co. etwas vorhersehbarer sind, ist der Einsatz von OKR für Product Discovery nicht auf den ersten Blick klar.

Ein erste Mehrwert entsteht, wenn nach dem OKR-Planning-Synchronisierungs-Prozess neue Themen für das Quartal klar sind und so auch ersichtlich wird, für welche Themen oder in welchen Richtungen Discovery-Arbeit notwendig sein wird.

Aufwände, Fortschritt und Erkenntnisse aus Discoveries werden zu selten für das gesamte Team oder andere Bereiche sichtbar gemacht. Findet sich die Discovery explizit in einem OKR wieder, kann dem entgegengewirkt werden. Durch die Präsenz im OKR Check-In fallen die Themen nicht unter den Tisch und können gemeinsam besprochen werden.

Ein “Hindernis” bei der Verbindung von OKR und Discovery stellt häufig das Timing dar. Wenn man erst nach der OKR-Definition zu Beginn eines Quartals mit einer neuen Product Discovery beginnt, sind die Chancen, die tatsächlichen Metriken zum Ende des Quartals mit einem releasten Produkt zu beeinflussen, recht gering. Daher sollten Produkt-Teams neben OKR für die tatsächliche Umsetzung auch schon vorausschauend Discovery OKR für die Begleitung ihres Dual-Track-Agile Prozesses definieren.

Da die OKR für das darauffolgende Quartal jedoch noch nicht formuliert sind, kommt wieder die Theme-based Roadmap ins Spiel: die Themen der NEXT-Spalte können als Orientierung verwendet werden.

OKR in Product Delivery integrieren

Einer der größten Hebel für fokussiertes Arbeiten mit OKR ist die Integration in das Task Management und die Routinen agiler Teams. Oft fällt es Teams schwer, den Beitrag einzelner Stories zum großen Ganzen einzuschätzen und ihre Arbeit entsprechend zu priorisieren.

Ein toller und einfacher Trick, den wir zuerst bei Michael Lindemeier von der Kartenmacherei gesehen haben, ist die Zuordnung einzelner JIRA-Issues zum jeweiligen Quartals-OKR. Mit einem simplen Custom Field in JIRA, wird so jeder Ticket-Ersteller und -Bearbeiter “gezwungen” sich darüber Gedanken zu machen, ob und warum es wirklich wichtig ist, an diesem Ticket zu arbeiten.

Das daraus automatisch resultierende Chart dient dann nicht dem Micromanagement des Teams, sondern der eigenen Awareness, ob man an den richtigen Dingen arbeitet. Wie oben schon erwähnt, sind ein paar Prozent von “non-OKR” Arbeit meistens unvermeidlich. Aber die Quantifizierung, in was Arbeit investiert wird, kann für Diskussionen im Team und mit Stakeholdern Gold wert sein.

OKR können ebenfalls in weitere Prozesse eingebunden werden. So lässt sich die Priorisierung für den nächsten Sprint mit einem Auge auf den Anteil von OKR-Issues leichter bewerkstelligen. Das Sprint Review lässt sich um ein Update zum Outcome des Teams ergänzen.

In den regelmäßigen Betrachtungen des OKR-Fortschritts wird dann nicht über den Fertigstellungsgrad einzelner User Stories gesprochen, sondern auf der daraus resultierenden Veränderung der Key Results. Wenn sich Key Results nicht oder “zu langsam” verändern wird entweder nicht an den richtigen Themen gearbeitet, oder die Key Results wurden nicht “richtig” gesetzt. So sind vielleicht zeitaufwändige Vorarbeiten notwendig, die bei der Definition der Key Results nicht berücksichtigt wurden.

Fazit

OKR können ein sehr wirksames Format sein, um Produkt-Teams zu mehr Fokus, Alignment und Autonomie zu verhelfen, vor allem durch die organisationsweite Synchronisierung der Ziele, die effektiveres und effizienteres Stakeholder-Management möglich macht.

Bei der Einführung ist es wichtig, sich über die Gründe der OKR Nutzung klar zu sein (sozusagen die OKR für die OKR Einführung), um das eigene OKR System von Beginn an so aufzusetzen, dass es zur heutigen Kultur der Organisation passt, aber auch die gewünschten Eigenschaften unterstützt. Über die Zeit kann dann gemeinsam Zyklus für Zyklus gelernt werden, ob und wie das Formulieren von Zielen und Messen von Fortschritten das Unternehmen und die Teams erfolgreicher macht. Hindernisse können durch die Auseinandersetzung offen gelegt und hoffentlich behoben werden.

Die Individualität gilt gleichfalls für die Verbindung hin zu agil arbeitenden Produkt-Teams und deren Prozessen. Um den Zusatzaufwand durch die neue Ebene “Zielformulierung für alle” gering zu halten, können die fortlaufenden OKR Elemente wie OKR Check-Ins und OKR Reflexion in vorhandene Prozesse und Routinen eingebettet werden.

Ob tatsächlich eine höhere Wirksamkeit der Arbeit erzeugt wird, hängt letztendlich davon ab, wie genau die OKR definiert und gelebt werden.