OKRs (Objectives and Key Results) sind eine feine Sache. Man kann sie in zwei Minuten erklären. Sie sind leichtgewichtig und man braucht keine Tools, um sie einzuführen. Plus, das Unternehmen und das Management können damit in ihrer Außenwahrnehmung punkten. „Wir sind agil, wir sind modern“.

Um was gehts denn?

Die ersten Schritte sind wie bei vielen „agilen“ Methoden und Frameworks vergleichsweise einfach. Danach wird es anstrengend. Nein, nicht nur anstrengend, es wird schmerzhaft. Geil. I love it! Nicht falsch verstehen, die Affinität zum Schmerz resultiert nicht etwa aus einer selbstzerstörerischen Neigung heraus. Schmerz ist vielmehr ein Indikator für eine oder mehrere Schwachstellen.

Von agilen Methoden wird verlangt, dass sie Probleme lösen, am besten sofort.

Und hier liegt der wahre Mehrwert agiler Methoden. Sie machen Schwachstellen sichtbar – im Team, im Geschäftsbereich oder im gesamten Unternehmen. Die Erwartungshaltung ist aber eine andere. Von agilen Methoden wird verlangt, dass sie Probleme lösen, am besten sofort – und, dass alles besser und schneller wird. Das macht den Schmerz erst richtig groß. Die Probleme verschwinden nicht nur nicht. Nein, sie werden sogar deutlicher. Siehe dazu auch „The Three Pillars of Empiricism – Transparency“.

Typische Verhaltensmuster

Das mögen weder Teams noch Führungskräfte. Ich beobachte drei wesentliche Verhaltensmuster, wenn agile Ansätze und Frameworks in diese Phase treten:

1. Ignorieren: Die einfachste Methode. Scrum, Kanban oder OKRs sind eingeführt. „Läuft, wir müssen uns jetzt um das nächste Ding kümmern!“ Resultat: Der schleichender Tod, die „Zombiisierung“ des Frameworks. Die dazugehörigen Artefakte und Zeremonien werden zum notwendigen Übel und irgendwann ist die Chance dahin, zu hinterfragen oder anzupassen. Die Situation erinnert an viele Beziehungen: „Jetzt sind wir schon so lange zusammen. Bloß nicht jetzt noch die Beziehung hinterfragen. Und was sollen die Kinder und unsere Freunde denken?“
2. Ersetzen: Den „Klassiker“ kennen wir von Scrum. Das Team findet Scrum doof, weil jeder Sprint gerissen wird und die vielen Zeremonien wertvolle Zeit für’s Coden fressen. „Lass‘ uns Kanban machen. Das ist schön „leichtgewichtig“ und Sprints gibt’s da auch nicht.“ Bei OKRs ist das ähnlich. Entweder man stoppt das Ganze, wenn es anstrengend wird – „Passt doch nicht so zu uns.“ – oder die nächste Sau wird durchs Dorf gejagt – „Wir machen jetzt nicht mehr OKRs, sondern OGSM.“ Das hält die „Org“ schön auf Trab und soll zeigen, dass man methodisch ganz vorne dabei ist. Symptombekämpfung. Auch ein Weg. Und schwups kann man erneut den (notwendigen) Schmerz, sich mit den eigentlichen Problemen zu beschäftigen, abwenden.
3. Analysieren: Hat eine Organisation die agile Denkweise wirklich verinnerlicht, dann begreift sie diese Phase nicht als Belastung, sondern als Chance. Jedem Akteur, auf allen Ebenen, ist bewusst, dass die Arbeit nach der Einführung von OKRs erst richtig losgeht. Nicht funktionierende Artefakte und Zeremonien als Symptom werden zum Anlass genommen, die eigentlichen Gründe für das „Nichtfunktionieren“ zu hinterfragen. Das ist zäh. Das ist ein Zeitfresser und hält zunächst vom Inhaltlichen ab. Mittel- und langfristig bewirkt es jedoch genau das, was jeder von agilen Frameworks erwartet: Mehr Geschwindigkeit durch klaren Fokus und höhere Eigenverantwortung der Teams bei geringstmöglicher Verschwendung.

Was machen denn OKRs?

An dieser Stelle werde ich nicht näher auf das Grundprinzip von OKRs eingehen. Das würde den Rahmen sprengen und ich gehe davon aus, dass sich die meisten von Euch schon mit dem Thema beschäftigt haben. Frau Wodtke herself fasst das Framework am besten zusammen:

[…] a system originated at Intel and used by folks such as Google, Zynga, LinkedIn […] to promote rapid and sustained growth. O stands for Objective, KR for Key Results. Objective is what you want to do (Launch a killer game!), Key Results are how you know if you’ve achieved them (Downloads of 25K/Day). OKRs are set annually and/or quarterly and unite the company behind a vision.

Wodtke, Christina. Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results (S.6). Kindle-Version.

Für mich liegt der „Charme“ von OKRs in zwei Dingen begründet: Zunächst die klarere Trennung zwischen dem WARUM und dem WAS auf der einen und dem WIE auf der anderen Seite. Werden OKRs richtig gelebt, entfaltet das Framework für die Teams eine ungeheure Kraft und Flexibilität, um die bestmöglichen Lösungen zur Erreichung der Ziele zu finden. Zum zweiten dienen OKRs, wenn richtig gelebt, als „Klebstoff“, sowohl zwischen den Teams als auch zwischen den Organisationsebenen. Letzteres liegt im kaskadierenden Prinzip des Frameworks begründet, das die Festlegung der eigenen Ziele immer aus einem übergeordneten Ziel fordert.

Die top 5 OKR Stolperfallen

Ich beschäftige mich schon seit einigen Jahren mit OKRs. Begonnen hat es mit einem Team, das Bock darauf hatte. Ganz im Sinne des anarchischen Prinzips haben wir einfach losgelegt, Erfahrungen gesammelt, ohne im ersten Schritt auf das offizielle „Buy-In“ der Führungsebene zu warten. Just do it. Dadurch konnten wir früh die fiesesten Stolperfallen kennenlernen, die ich Euch hier vorstellen möchte.

#1 – Der Klassiker: OKRs = Projektplan

Problem: Ihr habt OKRs auf Team- oder Bereichs-/Unternehmenseben definiert und es fühlt sich wie ein Projektplan – in neuem Gewand – an. Ein Indikator dafür kann sein, dass Objectives nicht nur die üblichen zwei bis drei Key Results (KRs) haben, sondern zehn oder mehr, ähnlich einer Check- oder Aufgabenliste. Ein weiterer Hinweis sind KRs, die als Aktivitäten formuliert sind. Beispiel: „Kennzahl xy zum Kundenreporting dazufügen“.

Ursachen: Eine Ursache kann mangelndes Vertrauen der Führungskräfte oder der Product Manager*innen in die Teams sein. Durch den abstrakten Charakter von OKRs droht ein Kontrollverlust über das WIE. Einer Projekt- und Output-orientierten Organisation fällt das besonders schwer. Auf Team-Ebene kann ein weiterer Grund für die „tasky-ness“ von KRs die zeitliche Verzögerung der Messbarkeit sein. Das ist dann der Fall, wenn neue Funktionen erst am Ende eines OKR-Zyklus ausgerollt werden und die Erfolgsmessung damit erst im darauffolgenden stattfindet.

Lösung: Dokumentation schafft Vertrauen. Wie schon erwähnt, bin ich Verfechter einer klaren Trennung zwischen dem WAS und dem WIE. Es spricht aber nichts dagegen, auch das mögliche WIE sichtbar zu machen. Das kann in Form eines (Epic-) Backlogs oder einer (agilen) Roadmap sein. Wenn Ihr solche Artefakte regelmäßig mit den Business-Verantwortlichen teilt und diskutiert schafft das Vertrauen in die Teams. Mit der Herausforderung einer zeitverzögerten Messbarkeit solltet Ihr pragmatisch umgehen. In dem Fall könnte man das KR zumindest als Zielzustand formulieren: „x Funktion(en) fehlerfrei für y Kunden bereitgestellt“. Im darauffolgenden OKR-Zyklus kann das Team dann im Rahmen der Optimierungen spezifische und messbare Produktmetriken als KRs nutzen.

#2 – Alles nur Business, wo bleibt die Funktion?

Problem: OKRs werden als reine „Business“-Ziele wahrgenommen. Im Endeffekt sind sie das auch. Bei allem, was wir tun, müssen wir immer die übergreifenden Ziele für unser Unternehmen im Blick haben. Was heisst das aber für unsere sogenannten „funktionalen“ Ziele, beispielsweise die Plattform technisch auf dem neuesten Stand halten oder ein professionelles Kennzahlen-Monitoring bereitstellen? Die Gefahr ist, dass solche elementaren Dinge in den Hintergrund geraten und die Teams ihrer funktionalen Verantwortung nicht mehr gerecht werden können.

Ursachen: Wahrscheinlich sind in diesem Fall die verantwortlichen Business-Abteilungen und/oder das Management thematisch zu weit von den typischen Problemstellungen einer Produkt- und Tech-Organisation entfernt. Zum zweiten werden Führungskräfte primär an klassischen „Business“-Kennzahlen gemessen und nicht an funktionalen Zielerreichungen.

Lösung: Gemeinsam mit den Tech- und UX- Leads ist es unsere Aufgabe als Product Manager*innen den Wert von funktionaler Expertise zu erklären. Die übergeordnete Kennzahl ist „Cost of Delay“. Das heisst, wenn die funktionale Basis nicht mehr stimmt, dann wird das mittel- bis langfristig massiven Einfluss auf die Business-Kennzahlen haben. Oder positiv ausgedrückt: Ein professionelles funktionales Fundament schafft uns als Unternehmen wichtige Wettbewerbsvorteile. Auf OKRs bezogen? Im ersten Schritt würde ich mit dem Management eine klar definierte „Functional Time“ aushandeln. Als Faustregel gelten bei Tech-Teams zum Beispiel 25-30%. Im nächsten Schritt etabliert man dann mit den Teams sogenannte „Functional“- oder „Tech“-OKR, die gleichberechtigt neben den „Business“-OKR stehen und in gleichem Maße geplant und überprüft werden.

#3 – Das neue Firmenmonster: Die OKR-Planung

Problem: Ui, ui, ui. Bei der flächendeckenden Einführung von OKRs im Unternehmen wächst das in der Theorie ach so leichtgewichtige Framework schnell zum epischen Meeting- und Workshop-Monster heran. Endlose Planungsmarathons wechseln sich mit zähen Abstimmungsrunden zwischen inhaltlich abhängigen Teams und Funktionen ab. „Klar, Planung gehört dazu und wir planen keinen zweiwöchigen Sprint, sondern ein komplettes Quartal. Aber so etwas? Nee, das haben wir uns anders vorgestellt!“

Ursachen: Keine Panik! Es ist völlig normal, dass neue Arbeitsweisen am Anfang viel Zeit kosten. Zudem macht es Sinn, sich an das Shu Ha Ri-Konzept zu halten und die Zeremonien „by the book“ zu erlernen, bevor man sie verschlankt. Daneben gibt es häufig einen weiteren Grund, den ich bei Firmen erlebt habe: Das Fehlen einer klaren Business-Strategie und eines professionellen Monitorings der wichtigsten Business- und Produkt-Kennzahlen. Oder: Strategie und KPI-Dashboard sind da, werden aber nicht richtig kommuniziert und operativ genutzt. Dadurch erleben wir vor jedem OKR-Zyklus den „Täglich grüßt das Murmeltier“-Effekt – Wir beginnen immer wieder von vorne, auf der „grünen Wiese“. Eine weitere Ursache kann ein übertriebenes basisdemokratisches Verständnis von agiler Planung sein. Als Folge schwellen die Workshops zu den besagten Monstern an, da bitte und gerne alle Mitarbeiter auf allen Ebenen mitbestimmen und -definieren sollen.

Lösung: Strategie machen und Kennzahlen anschauen! Bei letzterem empfehle ich eine Formalisierung der KPI-Betrachtung. Das heisst, diskutiert regelmäßig und am besten crossfunktional die top Business- und Produkt-KPI. Damit könnt Ihr kontinuierlich Handlungsempfehlungen als Basis für die nächsten OKR-Zyklen ableiten und müsst bei der Planung nicht jedes Mal bei Null starten. Falls Ihr noch in der Strategie-Findung seid, empfehle ich, mindestens die sogenannten MOALs (Mid-Term Goals) zu definieren. MOALs beschreiben – für eine Geschäftseinheit, eine Funktion oder das gesamte Unternehmen – den Fokus für die nächsten Quartale (z.B. ein Jahr), aus dem sich die OKRs in der Folge ableiten. Beim Thema Involvieren der Mitarbeiter empfiehlt sich ein Hybrid aus „Buttom-Up“- und „Top-Down“-Ansatz. Es ist völlig o.k., wenn die grobe Richtung bei der Planung schon steht. Dafür um so wichtiger, dass die Teams früh eingebunden werden, um Feedback zu geben und Zeit haben, ihre (Team)-OKR daraus zu konkludieren.

#4 – OKRs? Dafür ist der Product Manager zuständig

Problem: „OKRs sind so ein Business-Ding, da soll sich unser Product Manager drum kümmern.“ Nee, nee, Leute. OKRs sind, ähnlich einem Sprint oder besser: dem Sprint-Ziel, Sache des gesamten Teams.

Ursachen: Ein möglicher Grund kann die fehlende Affinität des Teams zu den Zielen (Objectives) sein. Das wiederum resultiert häufig aus einer schlechten Kommunikation der zugrunde liegenden Idee hinter den Zielen (siehe auch Leading by Intent – Die Geheimwaffe des Product Owners) und aus der fehlenden „Operationaliserung“ von OKRs auf Team-Ebene.

Lösung: Viele Organisationen leben ein mehrstufiges OKR-System. Dabei werden zum Beispiel im ersten Schritt die OKRs für die Geschäftsbereiche (L1) und davon abgeleitet, die OKRs in den zugehörigen Funktionen, Teams oder Squads (L2) definiert. Hier befindet sich schon gleich eine potentielle Bruchstelle. Nicht nur, weil „Business“- auf „Funktions“-Welt trifft, sondern weil häufig die Idee hinter den Objectives und Key Results (L1) nicht klar vermittelt wird. Auflösen kann man das, indem je ein, maximal zwei, Vertreter aus den Funktionen bei der Erstellung beteiligt werden. Des weiteren empfehle ich die Kommunikation schon auf Basis der ersten Version in einer kurzen „Sharing Session“, um so früh als möglich Feedback zu bekommen. Bei der „Operationalisierung“ der L2-OKRs habe ich gute Erfahrungen gemacht, wenn Teams einmal am Ende der Woche (5-10 Minuten nach dem Standup) gemeinsam mit ihrem/ihrer Product Manager*in den Status besprechen. Status bedeutet: 1. Fortschritt der KRs (Gradings) und 2. Zuversicht, die Ziele zu erreichen (Confidence).

#5 – Nur 100% Zielerreichung ist eine gute Zielerreichung

Problem: OKRs verfolgen ein anderes Prinzip als „traditionelle“ Business-Ziele. Während bei letzteren ein Erreichungsgrad von 70% häufig einem Desaster gleichkommt, kann das Ergebnis bei OKRs völlig o.k. sein. Man spricht bei OKRs auch von „shoot for the moon“. Das heisst, Teams setzen sich bewusst sehr ehrgeizige Ziele, die aber möglicherweise nicht erreicht werden können. Hier prallen zwei Welten aufeinander. Die Konsequenz kann sein, dass Teams kein Risiko mehr eingehen und Ihre Ansprüche reduzieren.

Ich zitiere an dieser Stelle wieder Frau Wodtke:

OKRs aren’t about hitting targets, but about learning what you are really capable of. Failure is a positive indicator of stretching. OKRs are designed to push you to do more than you knew you were capable of. If you shoot for the moon, you may not make it but it’s a hell of a view.

Wodtke, Christina. Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results (S.115). Kindle-Version.

Ursachen: Einer der Gründe kann sein, dass übergeordnete Kennzahlen wie Umsatz oder Profitabilität 1:1 als Objectives oder Key Results übernommen werden. Damit sitzt man in der Falle und schwächt die Kraft von OKRs. OKRs sind vielmehr die „Hebel“ und sollen in ihrer Summe zu einer Verbesserung der Business-KPI führen.

Lösung: Ich sehe zwei Ansatzpunkte. Zum einen solltet Ihr den Teams unabhängig von OKR-Zyklen helfen, ihre spezifischen „Hebel“ besser zu verstehen und damit den Kontext zu den „Business“-KPI herstellen. Das hilft, löst aber nicht immer den Konflikt der Zielerreichung. Hier bietet sich (ausnahmsweise) ein „dirty Hack“ an. Das Team setzt ein realistisches Ziel als 100% (Grading), der „shoot for the moon“ wird als zusätzliches Grading (z.B. 125%) definiert – Das gleiche in Grün, nicht gerade schön, aber alle Akteure sind happy – und das ist das Wichtigste ;-).

Was sind Eure top Stolperfallen bei OKRs? Hinterlasst mir gerne einen Kommentar oder schreibt mich direkt an.

Literaturtipp

Klickt, kauft und macht uns reich – unser Literarturtipp zum Thema. Das Standardwerk von Christina Wodtke für alle OKR-Jünger und die, die es werden wollen:

Bild 1: Mirador Del Rio (Lanzarote, Spanien) von Martin Heckmann