Im Internet findest Du zahlreiche OKR-Beispiele, die Dir dabei helfen sollen, bessere OKR zu formulieren. Das ist zwar nett zu lesen, bringt Dich jedoch nicht wirklich weiter. Denn Du kannst diese Beispiele ja nicht einfach kopieren und für Dein Team übernehmen. Viel hilfreicher ist es deshalb, problematische und schlechte OKR zu erkennen, um dann zu überlegen, wie Du diese Fehler vermeiden kannst.

In diesem Artikel stelle ich Dir deshalb 11 schlechte OKR vor und zeige Dir, warum sie problematisch sind, damit Du diese Fehler bei Deinen eigenen OKR-Formulierungen vermeiden kannst. Außerdem gebe ich Dir anschließend ein mögliches positives Beispiel, wie Du das OKR verbessern könntest.

Inhaltsverzeichnis

OKR-Beispiele mit problematischen Objectives

In den ersten drei OKR-Beispielen geht es um häufig anzutreffende Problem bei den Objectives: Evergreen-Objectives, Finalsätze und das Engima-Syndrom.

Evergreen-Objective

Was ist das Problem?

In diesem OKR-Beispiel ist das Objective als Evergreen formuliert, der für immer und alle Zeiten gültig ist. Aus diesem Grund ist überhaupt keine Situation denkbar, in der dieses Objective nicht sinnvoll wäre. Dadurch verliert dieses Objective jedoch an Aussagekraft, weil es eben selbstverständlich ist.

Eine gute Möglichkeit, um Evergreen-Objectives zu erkennen, ist der Wiederholbarkeits-Test. Dabei stellst Du Dir gemeinsam mit Deinem Team die simple Frage: „Könnten wir dieses Objective im nächsten OKR-Zyklus wieder genauso formulieren?“ Falls Ihr Euch diese Frage mit „Ja“ beantworten müsst, habt Ihr leider ein Evergreen-Objective formuliert.

Stell Dir Dein Objective als Aussichtspunkt oder Etappenziel vor. Welche neuen Perspektiven ermöglicht Dir das Erreichen dieses Objectives und welche Dinge kannst Du von Deinem Aussichtspunkt aus entdecken? Formuliere Dein Objective als abgeschlossenen, spezifischen Zustand, der genau das wiedergibt.

Evergreen-Objective

Evergreen-Objective

  • Wir begeistern unsere Kunden durch herausragenden Service!

  • Die Wartezeit zwischen Fehlermeldung und Rückmeldung durch den Service sinkt von 10 auf 1 Stunde.
  • Der Net Promoter Score im Service steigt von 10 auf 30.
  • Der Anteil der Bugs, die innerhalb von 2 Tagen gelöst werden, steigt von 50 auf 90 Prozent.

Objective als spezifischer Zustand

  • Wir steigern die Qualität und Geschwindigkeit bei der Bearbeitung von gemeldeten Fehlern.
  • Die Wartezeit zwischen Fehlermeldung und Rückmeldung durch den Service sinkt von 10 auf 1 Stunde.
  • Der Net Promoter Score im Service steigt von 10 auf 30.
  • Der Anteil der Bugs, die innerhalb von 2 Tagen gelöst werden, steigt von 50 auf 90 Prozent.

Finalsätze

Was ist das Problem?

Sehr oft werden auch OKR formuliert, deren Objectives als Finalsatz formuliert sind. Das Problem hierbei ist, dass nur ein Teil dieser Formulierung das eigentliche Objective ist, während hingegen der andere Satzteil eine (meist) konkrete Aufgabe angibt, wie das Ziel zu erreichen ist.

Das Problem dieses OKR-Beispiels lässt sich recht einfach an einer Um-Zu-Formulierung erkennen. Andere Wörter wie indem, damit oder durch sind ebenfalls ein Indikator dafür, dass in einem Objective das eigentliche Ziel mit dem Weg zum Ziel vermischt wurde.

In der Regel lässt sich das Problem solcher Objectives sehr einfach dadurch beheben, indem nur der Um-Zu-Satzteil für das Objective beibehalten wird. Das Mittel zum Zweck, das zuvor Teil des Objektives war, gehört jedoch nicht in die Key Results: Nutze die Idee besser als OKR-Initiative.

Finalsatz-Objective

  • Wir investieren in Automatisierung, um schneller Updates auszuliefern.

  • Der Installed Version Index sinkt von 30 auf 5.
  • Die Customer Cycle Time sinkt von 10 auf 4 Tage.
  • Die Länge unserer Sprints sinkt von 4 auf 2 Wochen.

Alternatives OKR-Beispiel

  • Wir verbessern unsere Fähigkeit, Updates schnell an unsere Kunden & Nutzer auszuliefern.

  • Der Installed Version Index sinkt von 30 auf 5.
  • Die Customer Cycle Time sinkt von 10 auf 4 Tage.
  • Die Länge unserer Sprints sinkt von 4 auf 2 Wochen.

Enigma-Syndrom

Was ist das Problem?

Dieser Fall tritt ein, wenn die Formulierung des Objectives zu viele Fachbegriffe verwendet, sodass nur speziell ausgebildete Kollegen verstehen, was damit gemeint ist.

Erkennen kannst Du dieses Problem am Vorhandensein von Spezialbegriffen und Fachchinesisch oder auch einem verschachteltem Satzbau.

Verwende kurze, einfache Sätze und Wörter, die für jeden verständlich sind. Als Test kannst Du Dein Objective auch Kollegen aus anderen Abteilungen zeigen, um herauszufinden, ob Dein OKR unmittelbar klar ist.

Enigma als Beispiel für kryptische OKR

Kryptisches Enigma-Objective

  • Wir supporten unsere stream-aligned Teams optimal durch Complicated-Subsystem- und Platform-Teams.
  • Die Anzahl der notwendigen Übergaben sinkt von 5 auf 0.
  • Die Schnittstellen unseres Produktes werden durch ein eigenständiges Team bearbeitet.

Alternative Objective-Formulierung

  • Wir verbessern unsere Teamstruktur für die Arbeit mit mehreren Teams am gleichen Produkt.
  • Die Anzahl der notwendigen Übergaben sinkt von 5 auf 0.
  • Die Schnittstellen unseres Produktes werden durch ein eigenständiges Team bearbeitet.

OKR-Beispiele mit problematischen Key Results

[wpdiscuz-feedback id=“xzviplrhib“ question=“Bist Du schon einmal in eine dieser Fallen getappt? Wie waren Deine Erfahrungen damit und wie hast Du das Problem gelöst?“ opened=“1″]Neben Objectives kommt es natürlich auch vor, dass die Formulierungen der Key Results Probleme verursachen können, die man gerne vermeiden möchte. In den folgenden 6 OKR-Beispielen findest Du daher Key Results, die diverse Schwierigkeiten verursachen und Tipps, wie Du diese vermeiden kannst.[/wpdiscuz-feedback]

Trojanisches Pferd

Was ist das Problem?

Manchmal kommt es vor, dass ein formuliertes Key Result eher den Charakter eines Objectives hat. Zum Beispiel, weil Du versuchst, mehrere Themen in ein OKR hineinzupressen und dabei die Anzahl der Key Results gering halten möchtest. Dadurch schmuggelst Du ein weiteres Objective als Trojanisches Pferd in Dein OKR. Das Problem daran ist, dass diese Key Results nicht messbar sind bzw. entweder erfüllt oder nicht erfüllt sind. Außerdem wird Dein OKR viel zu umfangreich.

Gut erkennen kannst Du dieses Problem daran, dass Dein Key Result keine Metrik enthält, sondern einen abgeschlossenen Zustand angibt, der erreicht werden soll. Das ist zwar eigentlich positiv, jedoch gilt dieses Merkmal eben für Objectives und nicht für Key Results.

In diesen Fällen musst Du in der Regel tiefgreifende Veränderungen vornehmen, weil sich Deine ursprüngliche Formulierung meistens nicht so leicht in ein einziges Key Result transformieren lässt. Oft kann es helfen, Dich zu fragen, woran Du erkennst, dass Du den von Dir formulieren Zustand erreicht hast.

OKR-Beispiel - Trojanisches Pferd

Key Results, die eigentlich Objectives sind

  • Wir verbessern die Zusammenarbeit an unserem Produkt.

  • Die Teamstruktur ist für die Arbeit mit mehreren Teams optimiert.

  • Der Release-Prozess ist automatisiert.

  • Die Struktur des Product Backlogs ist für die Arbeit mit mehreren Teams ausgelegt.

Beispiel für ein alternatives OKR

  • Wir verbessern die Zusammenarbeit an unserem Produkt.

  • Die Zufriedenheit der Teammitglieder mit der teamübergreifenden Zusammenarbeit steigt von 2,1 auf 3,8.

  • Die Zahl der während eines Sprints erkannten Abhängigkeiten zwischen Teams sinkt von 20 auf 5.

  • Die Zahl der notwendigen Übergaben an andere Teams sinkt von 5 auf 0.

Abhängigkeiten & Meilensteine

Was ist das Problem?

Zwischen Deinen Key Results existieren Abhängigkeiten, so dass sie nicht erreicht werden können, wenn andere andere Key Results des gleichen OKR nicht fertig sind. Zum Beispiel weil ein Key Result einem anderen logisch vorausgeht.

Gut erkennbar ist dieses Problem daran, dass Deine Key Results einen starken Objective-Charakter haben, weil sie als Meilenstein festgehalten wurden.

Die einfachste Lösung ist es, lediglich das letzte Key Result Deiner Meilenstein-Kette beizubehalten und die anderen zu streichen. Eventuell bieten sich die gestrichenen Key Results als OKR-Initiativen an. Manchmal kann es auch helfen, vollkommen neue Key Results zu entwerfen.

Meilensteine als Key Results

  • Wir erzielen erste Erfolge als Online-Anbieter.

  • Der Webshop ist fertig eingerichtet.

  • Die ersten 5 Produkte sind online gestellt.

  • Unsere Online-Produkte erzeugen 5.000 € Umsatz.

Alternatives OKR-Beispiel

  • Wir erzielen erste Erfolge als Online-Anbieter.

  • Unsere Online-Produkte erzeugen 5.000 € Umsatz.

  • Die Conversion-Rate des Webshops liegt bei 5 %.

  • 5 % unserer Newsletter-Abonnenten klicken auf Links zu unserem Webshop.

Schachtel-Key-Results

Was ist das Problem?

Das Objective enthält ein oder mehrere Key Results, die mehrere Metriken verwenden oder Bedingungen benennen, wodurch es nicht mehr eindeutig zu bestimmen ist. Hierdurch kommt es während des OKR-Zyklus zu Verwirrung, weil im Team eine unterschiedliche Meinung darüber herrscht, welchen Stand das Key Result aktuell hat oder was überhaupt genau gemessen wird.

Erkennbar ist dieses negative OKR-Beispiel vor allem daran, dass ein Key Result mehr als eine Metrik enthält. Außerdem tauchen in Schachtel-Key-Results Formulierungen wie „Je 10 Nutzer aus 5 Geschäftsfeldern“ oder „3 von 5 Kunden“ auf.

Fasse die Bedingungen und Metriken zusammen und einige Dich mit Deinem Team auf einen allgemeinen Wert, der gemessen werden soll. Die Trennung, die Du im Key Result vorgenommen hast, kannst Du trotzdem noch auswerten, falls Dir das wichtig ist. Sie gehört jedoch nicht in ein Key Result.

OKR-Beispiel - Schachtel-Key-Results

Verschachtelte Key Results

  • Die neuen Features unseres Produktes stiften einen echten Mehrwert für unsere Nutzer.

  • 50 Prozent der Nutzer aus jedem unserer 5 Geschäftsfelder bewerten unser neues Produkt mit 3,5 von 5 Sternen.

  • 2 von 5 Features werden mit 4 von 5 Sternen bewertet.

  • 5 von 10 Nutzern verwenden die neuen Features täglich.

Eindeutige Key Results mit nur einer Metrik

  • Die neuen Features unseres Produktes stiften einen echten Mehrwert für unsere Nutzer.

  • Die Bewertung des gesamten Produktes steigt von 2,2 auf 3,0.

  • Die Bewertung neuer Features steigt von 2 auf 3,5.

  • Der Customer Usage Index steigt von 2 auf 30 Prozent.

Hopp-oder-Top-Key-Results

Was ist das Problem?

Das Key Result enthält lediglich einen Zielwert und ist dadurch entweder „erreicht“ oder „nicht erreicht“. Im Verlauf des OKR-Zyklus führt das dazu, dass für das Key Result kein Fortschritt ermittelt werden kann. (Wenn der Zielwert solcher Key Results nicht erreicht wird, beträgt der Fortschritt immer 0 Prozent, weil es nicht erfüllt wurde.)

Erkennen lässt sich das Problem dieses OKR-Beispiels vor allem daran, dass Teams mit solchen Key Results die Tendenz haben, während des OKR Check-ins ihre Aufwände einzutragen oder den Fortschritt des Key Results zu raten bzw. zu schätzen. Manchmal liegt es auch daran, dass es sich bei dem Key Results in Wirklichkeit um ein Objective handelt. (Siehe oben.)

Nutze (wann immer möglich) sowohl einen Startwert als auch einen Zielwert für Key Results, um Deinen Fortschritt sichtbar machen zu können. Falls das nicht möglich ist, kannst Du auch den Confidence Level als Behelf verwenden.

Hopp-oder-Top-Key-Results

  • Wir steigern die Geschwindigkeit bei der Bearbeitung gemeldeter Fehler.
  • Die Wartezeit zwischen Fehlermeldung und Rückmeldung durch den Service beträgt maximal 1 Stunde.
  • Die Lead Time für gemeldete Bugs liegt bei 4 Tagen.

Key Results mit Start- & Zielwert

  • Wir steigern die Geschwindigkeit bei der Bearbeitung gemeldeter Fehler.
  • Die Wartezeit zwischen Fehlermeldung und Rückmeldung durch den Service sinkt von 10 auf 1 Stunde.
  • Die Lead Time für gemeldete Bugs sinkt von 10 auf 4 Tage.

Key Doings statt Key Results

Was ist das Problem?

In diesem Beispiel geht es darum, dass die Key Results Deiner OKR Aufgaben, Projekte oder Doings angeben, statt echte Ergebnisse. Dadurch kann es geschehen, dass Dein OKR zwar vollständig erreicht wurde, aber dieses gar nicht die gewünschte Wirkung erzielt. Darüber hinaus ist unklar, was die Wirkung überhaupt genau sein soll, weil sie gar nicht durch Key Results festgehalten wurde.

Die Key Results geben Aufgaben, To Do’s, Projekte oder Initiativen an, die erledigt werden müssen, um das Ziel zu erreichen.

Um dieses Problem zu lösen, solltest Du zunächst Deine bisherigen Key Results als OKR-Initiativen festhalten. Im zweiten Schritt musst Du Dich gemeinsam mit Deinem Team fragen, welches Ergebnis Du durch diese Aufgaben erzielen möchtest und wie Du messen kannst, dass Du es erreicht hast.

Aufgaben & Doings in Key Results

  • Wir verbessern unsere Fähigkeit, neue Features möglichst früh zu unseren Kunden zu bringen.

  • Wir investieren 30 % unserer Zeit in das Schreiben von Unit-Tests.

  • 2 neue Entwickler für unser Team wurden eingestellt.

  • Das WIP-Limit sinkt von 10 auf 5 Work Items.

Outcome-orientierte Key Results

  • Wir verbessern unsere Fähigkeit, neue Features möglichst früh zu unseren Kunden zu bringen.

Output-Key-Results

Was ist das Problem?

Diese Art von OKR ist dem vorherigen Beispiel recht ähnlich. Allerdings wird durch die Key Results nun nicht mehr der Input, sondern der Output beschrieben. Das ist zwar schon ein kleiner Fortschritt, jedoch verursachen solche Key Results das gleiche Problem: Es kann geschehen, dass Du Dein OKR erreichst, aber die von Dir gewünschte Wirkung (Outcome) ausbleibt.

Die Key Results solche OKR können direkt durch Eure Maßnahmen (Input) erreicht werden, weil zwischen Input und Output eine kausale Verbindung besteht. Bei ergebnis-orientierten Key Results hingegen ist diese Verbindung nicht direkt, sondern muss erst ermittelt werden. Denn es nicht immer sicher, ob durch den Output eines Teams auch der gewünschte Outcome erzielt wird.

Sprich mit Deinem Team über die Unterschiede zwischen Output und Outcome. Überlegt gemeinsam, welche Metriken Euch dabei helfen können, das Ergebnis (Outcome) zu messen, das Ihr durch Euren Output erzielen wollt.

Output in Key Results

  • Wir verbessern unsere Fähigkeit, neue Features möglichst früh zu unseren Kunden zu bringen.

  • 80 % aller User Stories können automatisiert getestet werden.

  • 12 von 14 Sprintzielen in diesem Quartal wurden erreicht.

  • 4 von 5 Features wurden an unsere Nutzer ausgeliefert.

Outcome-orientierte Key Results

  • Wir verbessern unsere Fähigkeit, neue Features möglichst früh zu unseren Kunden zu bringen.

Beispiele für übergreifende Probleme in einem OKR

Neben Problemen, die direkt auf das Objective oder die Key Results zurückzuführen sind, gibt es auch noch ein paar Beispiele, bei denen das gesamte OKR ungewünschte Seiteneffekte verursachen kann. Hier liegen die Probleme also sowohl in den Objectives als auch in den Key Results. Besonders oft sind Komfortzonen-OKR und Key Results ohne Bezug zum Objective anzutreffen.

Komfortzonen-OKR

Was ist das Problem?

In diesem Beispiel geht es darum, dass Dein Team nur die OKR formulieren möchte, die es auch sicher erreichen kann. Beispielsweise weil es kein Risiko eingehen möchte, sich später vor anderen rechtfertigen zu müssen oder weil es bei seinen letzten OKR krachend gescheitert ist.

Dein Team spielt auf Nummer sicher. Sehr oft tendiert es dazu, bei den Key Results Output oder sogar Input festzuhalten, weil diese sicherer erreichbar sind als outcome-orientierte Key Results. Außerdem hat Dein Team den Hang, Metriken sehr niedrig anzusetzen, sodass es sicher sein kann, das OKR bis zum Ende des Zyklus auch erreichen zu können.

Dieses Problem lässt sich leider nicht durch eine bessere Formulierung beheben. Die Ursachen hierfür liegen nämlich in der Teamkultur. Um Dein Team dazu zu bewegen, sich anspruchsvolle Ziele bzw. Stretch Goals zu setzen, bedarf es vor allem einer offenen und positiven Fehlerkultur. Diese entsteht jedoch nicht von alleine, sondern nur durch agile Führung.

Auch eine schlechte oder nicht vorhandene Psychologische Sicherheit kann dazu führen, dass ein Team sich hauptsächlich in seiner Komfortzone bewegt.

Komfortzonen-OKR-Beispiel

Key Results ohne Bezug zum Objective

Was ist das Problem?

Die Key Results, die Du festgehalten hast, passen nicht zu Deinem Objective und vermitteln nicht, wann Du es erreicht hast.

Bei diesem negativen OKR-Beispiel ist gesunder Menschenverstand gefragt. Manchmal hilft es, jemand Unbeteiligtem Dein OKR zu zeigen. Trag es dieser Person vor und nutze dabei folgende Formulierung: „Unser Ziel ist [Objective]. Wir wissen, dass wir es erreicht haben, wenn wir [Key Results].“ Dadurch erhältst Du wertvolles Feedback darüber, ob Deine Key Results zu Deinem Objective passen oder nicht.

Hier musst Du abwägen. Wenn Du feststellst, dass Dir die Key Results gut gefallen, musst Du eine neue Formulierung für Dein Objective finden, das besser zu ihnen passt. Willst Du hingegen an Deinem Objective festhalten, bleibt Dir nichts anderes übrig, als die bisherigen Key Results zu verwerfen und neue festzuhalten. Frage auch andere um Rat, welche Key Results ihnen zu Deinem Objective einfallen.

Fazit zu den OKR-Beispielen

Ich hoffe, ich konnte Dir mit diesen OKR-Beispielen dabei helfen, Probleme, die durch bestimmte Formulierungen entstehen können, besser zu verstehen. Natürlich wird es Dir nicht immer gelingen, jedes Problem zu vermeiden. Wenn Du beispielsweise über ein Key Result eine neue Metrik in Deinem Team oder Deiner Organisation einführst, wirst Du nur in den seltensten Fällen einen Startwert für Deine Metrik haben. Manchmal ist es besser, ein Problem zu akzeptieren als es auf Biegen und Brechen zu beheben.

Falls Du noch Fragen, Ideen, Anregungen oder Kritik zu diesem Artikel hast (oder Dir noch OKR-Beispiele fehlen), freue ich mich über Dein Feedback in den Kommentaren und auf der Seite!