Die Immunabwehr deiner OKRs: Anti Key Results

Jede Kennzahl kann ausgetrickst werden. Jede Kennzahl kann zu Schaden führen. Das sind Probleme, die inhärent in allen Metriken eingebaut sind. Es gibt aber Möglichkeiten, deine Ziele robuster zu machen, also eine Art Schutzimpfung durchzuführen. Das gelingt dir mit Anti Key Results.

Andy Grove wusste die Lösung …

Marc Andreessen, Erfinder des modernen Webbrowsers und Finanzinvestor, sagte einmal1:

"Andy Grove wusste die Lösung: Für jede Kennzahl sollte es eine entsprechende Kennzahl geben, die sich auf die negativen Folgen der ersten Kennzahl bezieht.«"

Klick hier für einen Tweet

Andy Grove, ehemaliger CEO von Intel und Vater der OKRs wusste in der Tat, dass Kennzahlen auch Schattenseiten haben. Die Schattenseiten und die Lösung von Andy Grove schauen wir uns jetzt gemeinsam an.

Was ich nicht messen kann, das …

Das Framework OKR setzt auf messbare Key Results oder auf Deutsch, Kernergebnisse.

Messbarkeit hat eine Reihe von Vorteile, die sich in der Praxis immer bewähren:

  • Erst Messbarkeit macht Fortschritt erkennbar
  • Nur messbare Kriterien ermöglichen den Nachweis von Erfolg
  • Messbare Kriterien schärfen das Denken: Wie sieht der gewünschte Zielzustand konkret aus?

Dem Management-Vater, Peter Drucker, wird folgendes Zitat zugeschrieben:

"Was ich nicht messen kann, kann ich nicht lenken. (Peter Drucker)"

Klick hier für einen Tweet

Gleichwohl, wir wissen, dass Kennzahlen und Messungen gefährlich sein können.

Ich möchte auf zwei dieser Risiken jetzt näher eingehen.

Risiko 1: Goodharts Gesetz

Das erste Risiko ist unter dem Begriff von Goodharts Gesetz bekannt:

Goodhart’s Law by sketchplantions

Wenn eine Messung mit Anreizen oder Sanktionen belegt wird, funktioniert diese Messung nicht mehr. Die Menschen fangen an, die eigentliche Intention der Messung zu umgehen. Sie spielen die Messung gegen die eigentliche Absicht aus.

Dieses Risiko ist besonders gravierend, wenn eine Leistungsmessung auf Output zur Bewertung von Teams oder Individuen vollzogen wird. Die agile Metrik „Velocity“ ist so ein Fall, bei dem diese Idee ad absurdum geführt wird, sobald das Team auf die Verbesserung der Zahl motiviert wird.

Risiko 2: Zielerreichung um jeden Preis

Das zweite Problem der Messung ist eine übermäßige Fokussierung auf das Ziel. Das Ziel wird zwar erreicht, aber es entsteht ein Kollateralschaden.

Dazu ein einfaches Beispiel.

Ein OKR für eine neue Business-Unit könnte sein 2:d

O: Wir wachsen

KR: Wir gewinnen 10.000 Neukunden

Eine extreme Möglichkeit der Kundengewinnung wäre es, Interessenten dafür zu bezahlen, dass sie Kunden werden. Ziel erreicht!

In der Tat ist diese Form der Kundengewinnung bei Start-ups häufig zu beobachten. Die Kunden werden nicht bezahlt, aber jeder neue Kunde erzeugt ein Defizit, um das Wachstum zu beschleunigen.

Lösung: Anti-Key-Results (AKR)

Eine Lösung für das Problem ist das, was Andy Grove gemacht hat. Er hat in seinen OKRs weitere Key Results eingebaut, die ich der einfach halber als Anti Key Results bezeichne.

Anti-Key-Results sind die Immunabwehr gegen die zuvor aufgezeigten Risiken. Sie schützen das OKR davor, dass sprichwörtlich das Kind mit dem Bade ausgeschüttet wird oder die OKRs einfach nur ausgetrickst werden.

Ein Beispiel für ein Anti-Key-Result

Ich illustriere das Konzept der Anti Key Result mit einem Beispiel aus der Software-Entwicklung. Ein Team startet für ein Produkt eine Qualitätsoffensive. Das Team möchte im nächsten Zyklus möglichst viele Fehler bereinigen.

O: Wir killen die Bugs

KR: Wir bereinigen im nächsten Zyklus 50 % unserer Defekte (350 Tickets)

Im schlimmsten Fall sind alle 350 Tickets wirklich geschlossen. Warum wäre das schlimm? Nun, weil das erhebliche Risiko besteht, dass 9 Wochen später wieder neue 350 Tickets aufgemacht werden.

Zwei mögliche Probleme könnten sein:

  1. Die Bereinigung der Fehler erfolgt um jeden Preis. Es werden alle Tickets geschlossen, aber die Fehlerbereinigung ist ein Flickenteppich.
  2. Die Fehlerbereinigung würgt andere Kapazitäten, beispielsweise für Anforderungen, im nächsten Zyklus ab.

Eine Lösung für dieses Problem können Anti Key Results sein3

O: Wir killen die Bugs

KR1: Wir bereinigen 25 % unserer Defekte (ca. 350 Tickets)

AKR1: Wir reservieren 50 % unserer Kapazität für Fehlerbereinigung

AKR2: Die Definition of Done wird zu 100% eingehalten (Unit-Tests, Testabdeckung, etc.)

AKR3: Fehler werden im Pair- oder Mob-Programming bereinigt.

In diesem Fall gibt es 3 Anti-Key-Results, damit wir mit der Fehlerbereinigung nicht das Kind mit dem Bade ausschütten. Und möglicherweise müsste vor dem Hintergrund das Key Result nach unten abgesenkt werden, aber das wäre nicht schlimm.

Meine 3 Tipps zur Formulierung von Anti Key Results

Meine drei Tipps zur Formulierung von Anti-Key-Results:

  1. Prüfe, ob dein OKR zu einer Gefährdung in anderen Bereichen führt. Baue dann ein AKR als Sicherung für den gefährdeten Bereich ein.
  2. Betrachte die Anti-Key-Results als Sicherungskasten. Frage dich, was bei einer extremen Verfolgung der Ziele schiefgehen kann und sichere das durch ein Anti Key Result ab.
  3. Wenn dir kein Anti-Key-Result zu deinen Key Results einfällt, ist das ein Indikator dafür, dass deine Key-Results vielleicht noch Output orientiert sind. Prüfe das.

Fazit

Überlege dir der Nutzung von OKR, ob mit der Zielerreichung Risiken verbunden sind. Denke an Andy Grove und Goodharts Gesetz. Hast du mit den Key Results wirklich die Absichten hinter dem Objektive genau formuliert, oder kann das System ausgespielt werden? Und denke daran, ob durch eine maximale Fokussierung auf das Ziel, die Luft zum Atmen wegbleibt und Folgekosten oder Schäden entstehen.

Tipp: Mein Onlinekurs “Effektive Key Results”

Ich werde bald einen Online-Kurs zum Thema „Effektive Key Results“ veröffentlichen. Falls du Interesse an dem Kurs hast, schreibe mir eine Mail an infoandreclaassen.de und sichere dir einen 25% Bonus zum offiziellen Startpreis. Du gehst keine Verpflichtung ein. Du sicherst nur deinen Bonus, was auch ein schönes Anti Key Result darstellen kann.

  1. Quelle: Tools der Titanen von Tim Ferris ↩︎

  2. Der Einfachheit halber, verwende ich O für das Objective (qualitatives Ziel) und K für die Key Results (Kernergebnisse) ↩︎

  3. Natürlich gibt es weitere Lösungen. Die wichtigste wäre eine gut funktionierende Definition of Done und klare Prozesse in der Fehlerbereinigung. Das Beispiel soll nur das Konzept der Anti Key Results illustrieren ↩︎

comments powered by Disqus