OKR-Fallstricke: Priorisieren, aber mit Fokus

In der Produktentwicklung – insbesondere in der agilen – gibt es einige Mythen und Methoden, die zwar hoch gepriesen werden, in der Praxis aber bei weitem nicht die Heilsbringer sind, als die sie verkauft werden. Wenn es um die Priorisierung von Projekten geht, steht eine Methode ganz oben auf der Liste: Objectives and Key Results (OKR). OKR können hilfreich sein, aber oft gibt es Probleme bei ihrer Anwendung. In diesem Artikel erläutere ich diese Fallstricke und wie man sie vermeiden kann.

Doch bevor es in diese Details geht, stellt sich zuerst die Frage: Warum ist Priorisierung wichtig?

(Produkt-) Ideen gibt es typischerweise viele – im Überfluss. Was jedoch in aller Regel nicht im Überfluss vorhanden ist, ist die Kapazität, um diese Ideen umzusetzen. Meist ist sie der begrenzende Engpass in der Produktentwicklung.

Aus diesem Grund müssen wir entscheiden, wofür wir diese Kapazität einsetzen. Es gibt viele Priorisierungsmethoden, aber eine ist die mit Abstand bekannteste: Objectives and Key Results. [1]

Wie funktionieren sie?

Die OKR-Methode in Kürze

Im Wesentlichen bestehen OKR aus zwei Grundkonzepten:

• Objectives: Diese sollen ambitionierte Ziele sein, wie z. B. „Wir erschließen ein neues Kundensegment.“
• Key Results: Sie gehören zu einem Objective und sollen messbare Schritte sein, um dieses zu erreichen. Z. B. für das obige Objective könnte ein Key Result lauten: „Wir gewinnen 4.000 neue Kunden aus diesem Segment, die unser Produkt A mindestens dreimal nutzen.“

Diese Objectives und Key Results können auf mehreren Organisationsebenen existieren.

Übergeordnete Ebenen geben mit ihren OKR die strategische Richtung vor. Untergeordnete Ebenen sollen mit ihren OKR wiederum die OKR der übergeordneten Ebene unterstützen, bzw. auf diese einzahlen.

Praktisch heißt das, dass Unternehmens-OKR von Bereichs-OKR unterstützt werden, die wiederum von OKR ihrer jeweiligen Untereinheiten unterstützt werden.

Abbildung 1: Die OKR-Methode

OKR werden für einen definierten Zeitraum – typischerweise drei Monate – vorab definiert und dann bearbeitet. Der Fortschritt wird idealerweise während des Zyklus überprüft, spätestens jedoch am Ende. Basierend auf diesen Erkenntnissen werden neue OKR für den nächsten Zyklus geplant.

Durch diesen Prozess sollen Ziele klar, Ergebnisse messbar und Teams auf gemeinsame Ziele ausgerichtet sein. Was kann da schon schiefgehen?

Typische Fallstricke bei der Verwendung von OKR

Einige typische Fallstricke sehe ich bei der Verwendung von OKRs immer wieder:

Ausufernder Abstimmungsaufwand

Die Vorbereitung und Planung von OKR kann enormen Aufwand produzieren.

Wenn Organisationseinheiten übergeordnete Ziele unterstützen wollen, z. B. „Wir erschließen ein neues Kundensegment“, können die Ansätze, wie sie dieses Ziel unterstützen, sehr unterschiedlich ausfallen. In einer nicht-trivialen Organisation werden diese unterschiedlichen Ansätze jeweils Unterstützung von anderen Einheiten benötigen.

Deshalb verbringen alle Einheiten vor jedem Zyklus Unmengen an Zeit damit, ihre Ideen vorzubereiten, vorzustellen und mit anderen abzustimmen. Das passiert vor allem, wenn man Projekte statt Ziele plant – was man unbedingt vermeiden sollte. Ich habe Fälle erlebt, in denen das gesamte Unternehmen zwei Wochen lang damit beschäftigt war, nur die nächsten OKR vorzubereiten.

Abbildung 2: OKR Abstimmungsaufwand

Fehlender Fokus

Ein weiteres typisches Problem ist der Verlust von Fokus während des OKR-Zyklus.

Angenommen, jedes Team arbeitet bereits fokussiert an seinen OKR. Nun entdeckt ein Team eine Abhängigkeit zwischen den OKR und bietet ein anderes Team um Unterstützung. Das Argument lautet dann meist: „Ihr müsst uns helfen – das Thema steht in den OKR!“

Je größer die Organisation, desto mehr Abhängigkeiten, desto mehr Anfragen – und desto weniger Fokus bleibt für ein Team.

Oft machen sich Organisationseinheiten oder Teams das Leben auch selbst schwer, indem sie viel zu ambitioniert planen. Wenn für 3 Monate 5 Ziele mit jeweils 3-5 Key Results geplant werden, ist das vielleicht einfach zu viel.

Ich habe einen Fall erlebt, in dem die Wände eines ganzen Raumes mit den OKR aller Teams bedeckt waren. Ob das Klarheit und Fokus schafft?

Abbildung 3: Fehlender Fokus bei OKR

Abwesende Agilität

OKR wirken theoretisch sehr agil, sind es aber oft nicht.

Abbildung 4: Agile ORK-Zyklen in der Theorie

Welche Vorhaben dauern schon genau drei Monate? Die wenigsten.

Oft werden Initiativen nach drei Monaten aber einfach fallen gelassen. Andere Stakeholder (die im letzten Zyklus vielleicht leer ausgegangen sind) wollen nun aber wirklich ihre Anforderungen priorisiert sehen.

Abbildung 5: Eine Serie von Mini-Wasserfällen

Das Ergebnis: Produkte werden nicht optimiert, ein Product-Market-Fit wird nicht erreicht und langfristige Innovation leidet zugunsten kurzfristiger Prioritäten.

Das ist nicht agil.

Wie funktioniert es besser?

OKR müssen aber nicht so katastrophal sein und können durchaus funktionieren.

Die folgenden Tipps helfen, OKR effektiver zu nutzen:

• Begrenzen Sie die Anzahl von Objectives und Key Results – und zwar strikt (~3 sind vernünftig, aber das variiert je nach Kontext). Sollte am Ende des Zyklus wider Erwarten noch Zeit übrig sein, wird niemand böse, wenn das Team mehr liefert als geplant.
• Bestimmen Sie für jedes Objective frühzeitig einen Verantwortlichen, der das Ziel, die entsprechenden Key Results und alle Abhängigkeiten koordiniert – über die ganze Zeit.
• Verplanen Sie maximal 60 % der Kapazität. Die restliche Kapazität wird für das operative Geschäft, unerwartete Anfragen oder Wartung und Bugfixing benötigt. Im besten Fall bleibt Zeit, um andere zu unterstützen oder mehr zu liefern.
• Planen Sie Ziele, keine Projekte! Ein wirklich gängiges Negativbeispiel ist das Planen von Projekten in OKR. Dafür sind Objectives and Key Results nicht gedacht und das ist auch die falsche Herangehensweise. Geht es nur um das Liefern des Projektes, so ist es am Ende egal, ob daraus ein Nutzen entsteht. Das Projekt wurde geliefert, also ist alles top!

Und zu guter Letzt sollten Objectives langfristig stabil bleiben. Sie können über mehrere Zyklen unverändert bleiben, bis sie erreicht oder bewusst depriorisiert werden.

Was Objectives and Key Results nicht leisten können

Darüber hinaus halten sich hartnäckig einige Missverständnisse über OKR, die auch dadurch begünstigt werden, dass sie gerne als Allheilmittel angepriesen werden.

Objectives and Key Results ersetzen nicht:

• eine Strategie,
• einen Produktentwicklungsprozess,
• einen Planungs- und Designprozess oder
• einen Konfliktlösungsprozess.

All das braucht eine Organisation zusätzlich. OKR definieren nur Prioritäten: „was wichtig ist.“

Was auch oft missverstanden wird: Objectives and Key Results liefern kein Lösungsdesign. Sie klären das „Was“, nicht das „Wie“. Ein Lösungsdesign folgt erst später – andernfalls würden wir wieder Projekte priorisieren.

Das bedeutet wiederum auch, dass OKR nur sehr begrenzt bei der Abstimmung zwischen Teams helfen können. Da das Lösungsdesign erst später folgt, sind die Abhängigkeiten z. B. zu anderen Teams bei der Planung noch unbekannt. Solange ich nicht weiß, was ich entwickeln will, kann ich nicht wissen, welche Teams betroffen sein werden.

Fazit

Objectives and Key Results sind nicht das Allheilmittel, als welches sie manchmal dargestellt werden. Das heißt nicht unbedingt, dass man sie nicht verwenden kann. Wenn man bisher ganz ohne Priorisierung gearbeitet hat, sind OKR sicherlich ein Schritt nach vorn. Ebenso hilfreich sind sie, wenn einzelne Abteilungen oder eine kleine Unternehmensorganisation sie verwenden.

Spätestens bei größeren Unternehmen sollte man allerdings gut darauf achten, die beschriebenen Fallstricke zu vermeiden.

In keinem Fall soll dieser Artikel davon abhalten zu priorisieren. Ohne Priorisierung arbeitet eine Organisation an den falschen Themen, an zu vielen Themen, an gegensätzlichen Themen, sprich: ineffizient. Das kann sich kein Unternehmen leisten. Dann lieber OKR mit den hier vorgestellten Tipps!

Hinweise:

[1] Hier finden Sie weitere Informationen zu OKR Vorteilen, Tipps zur Einführung und Fragen aus der Praxis.

Jan Hegewald bloggt unter https://www.agil-gefuehrt.de über moderne Führung und Agilität. Sein Newsletter The Tech Impact Uplift beschreibt, wie Tech-Organisationen mehr Wert für Kunden erbringen können. Auf LinkedIn können Sie leicht mit ihm Kontakt aufnehmen.

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk.

Jan Hegewald hat weitere Beiträge im t2informatik Blog veröffentlicht: