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:
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:
- Die Bereinigung der Fehler erfolgt um jeden Preis. Es werden alle Tickets geschlossen, aber die Fehlerbereinigung ist ein Flickenteppich.
- 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:
- 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.
- 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.
- 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.
Photo: sketchplantions
-
Quelle: Tools der Titanen von Tim Ferris ↩︎
-
Der Einfachheit halber, verwende ich O für das Objective (qualitatives Ziel) und K für die Key Results (Kernergebnisse) ↩︎
-
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 ↩︎
