Was wäre, wenn wir unsere OKRs wie Code behandeln würden?

Ich habe einen großen Teil meiner Karriere im Bereich Continuous Integration (CI) und Continuous Delivery (CD) verbracht (hallo Atlassian Bamboo, hallo Bitbucket Pipelines 👋). Eine Sache war mir klar, als wir Tability gebaut haben: Wir mussten uns einige Ideen aus dem Engineering ausleihen, um das OKR-Problem zu lösen.

Moment, was ist eigentlich das Problem mit OKRs?

Ich empfehle dir sehr das Buch von Christina Wodtke, Radical Focus, da es eine der häufigsten Fallen von OKRs veranschaulicht: Man vergisst sie.

So läuft die Geschichte meistens ab. Ein Team ist über den Punkt hinausgewachsen, an dem die Gründer noch den Überblick behalten können. Sie fangen an, nach einer besseren Methode zu suchen, um die Arbeit zu organisieren. Sie hören oder lesen von OKRs. Sie lieben es! Sie definieren das erste Set an OKRs und packen alles in eine Tabelle. Alle sind begeistert. Sie fangen an, an den wichtigsten Prioritäten zu arbeiten.

Einen Monat später: Niemand kann sich mehr erinnern, wie die OKRs lauteten, und alle gehen wieder in unterschiedliche Richtungen. Sie haben all ihre Energie in die Planung gesteckt und vergessen, eine Methode zur Fortschrittsverfolgung festzulegen.

Aus den Augen, aus dem Sinn.

Arbeit ist paradoxerweise ein mächtiger Generator von Ablenkungen. Jedes Projekt scheint einen Haufen zusätzlicher Funktionen zu entwickeln und wird zu einem riesigen Tintenfisch, der das Team als Geisel hält. Jede Woche bringt Dutzende von Anrufen, Hunderte von E-Mails, die deine Aufmerksamkeit von deinen Hauptprioritäten ablenken. Jede Aufgabe hat ihre eigenen unbekannten Unbekannten die dich tief in den Kaninchenbau ziehen.

Kommen wir also zurück zu unseren OKRs: Sie sind zum Scheitern verurteilt, wenn wir nicht irgendeine Art von Rahmenwerk haben, das sie unterstützt. Nicht weil das Team sich nicht darum kümmert, sondern weil ihm die Zeit fehlt, darüber nachzudenken — es sei denn, wir fordern es aktiv ein.

CI/CD-Prinzipien zur Rettung

Hier ist eine Definition von Continuous Integration von Martin Fowlers Website.‍

Continuous Integration ist eine Softwareentwicklungspraxis, bei der Teammitglieder ihre Arbeit häufig integrieren, in der Regel integriert jede Person mindestens einmal täglich - was zu mehreren Integrationen pro Tag führt. Jede Integration wird durch einen automatisierten Build (einschließlich Tests) überprüft, um Integrationsfehler so schnell wie möglich zu erkennen. Viele Teams stellen fest, dass dieser Ansatz zu deutlich weniger Integrationsproblemen führt und es einem Team ermöglicht, kohärente Software schneller zu entwickeln.‍

Richtig — das ist super technisch. Es geht also nicht so sehr darum, CI in deinen Tabellen zu aktivieren, sondern eher darum zu verstehen, warum es ein beliebter Ansatz in der Softwareentwicklung ist.

Produktteams auf der ganzen Welt haben CI/CD übernommen, weil sie erkannt haben, dass schnelle Iterationen viel bessere Ergebnisse liefern als eine großspurige Planung mit einem Wasserfall-Ansatz bei der Umsetzung. Fortschritt früh und oft zu überprüfen, reduziert die Kosten, falsch zu liegen, und ermöglicht es dir, deine Richtung durch Feedback von deinen Kunden zu validieren.

Die Sache wird noch interessanter, wenn man sich die 5 Prinzipien von Continuous Delivery ansieht, veröffentlicht von Jez Humble:

1. Qualität von Anfang an einbauen
2. In kleinen Schritten arbeiten
3. Computer erledigen sich wiederholende Aufgaben, Menschen lösen Probleme
4. Unablässig kontinuierliche Verbesserung anstreben
5. Jeder ist verantwortlich

Ich glaube fest daran, dass du diese Prinzipien auch auf den OKR-Prozess anwenden kannst und solltest.

Die 5 Prinzipien der OKRs

Qualität von Anfang an einbauen

„Es ist viel günstiger, Probleme und Fehler zu beheben, wenn wir sie sofort finden“

Warte nicht bis zum Ende des Quartals, um festzustellen, dass eines deiner Key Results vom Kurs abgekommen ist. Ein täglicher Rhythmus für OKRs ist zu viel, aber du solltest den Fortschritt deiner Key Results jede Woche überprüfen (idealerweise montags, um nach dem Wochenende wieder reinzukommen). Kümmere dich um jedes KR, das seit mehr als 2 Wochen rot ist.

In kleinen Schritten arbeiten

„Es verkürzt die Zeit, die man braucht, um Feedback zu unserer Arbeit zu bekommen, erleichtert die Triage und Behebung von Problemen, erhöht Effizienz und Motivation und verhindert, dass wir dem Sunk-Cost-Trugschluss erliegen.“

Sätze wie „wir können den Fortschritt erst nächsten Monat verfolgen“ sind Warnsignale. Die Arbeit, die geleistet wird, um bei den Key Results voranzukommen, sollte innerhalb von Wochen und nicht Monaten eine Wirkung zeigen.  Setze nicht auf große Würfe. Gib dein Bestes, um über das ganze Quartal hinweg inkrementelle Fortschritte zu erzielen.

Computer erledigen sich wiederholende Aufgaben, Menschen lösen Probleme

„Das Ziel ist, dass Computer einfache, sich wiederholende Aufgaben erledigen, wie zum Beispiel Regressionstests, damit sich Menschen auf das Lösen von Problemen konzentrieren können“

Dies ist eine Warnung vor zu viel Automatisierung bei OKRs. Ich habe Fälle gesehen, in denen Teams wollten, dass der Fortschritt bei Key Results automatisch über Skripte oder Integrationen aktualisiert wird, ganz ohne menschliches Eingreifen.

Das zerstört die Vorteile von OKRs, da der Teil der Problemlösung verloren geht. Der Wert von OKRs entsteht dadurch, dass (1) Menschen an die wichtigsten Prioritäten erinnert werden und (2) Menschen aktiv über die Lücke zwischen ihrem aktuellen Stand und ihrem Ziel nachdenken.

Vollständige OKR-Automatisierung nimmt die menschliche Note weg. Computer sollten dir helfen, die Daten zu sammeln, aber nur dein Team kann sie interpretieren und nutzen, um wichtige Entscheidungen zu treffen.

Unablässig kontinuierliche Verbesserung anstreben

„Behandle Transformation nicht als ein Projekt, das man angeht und dann abschließt, um zum Alltagsgeschäft zurückzukehren.“

Ich finde, OKRs leiden etwas unter ihrer Geschichte. Es ist ein Prozess, der oft mit der Führungsebene und großen Unternehmen assoziiert wird, und er klingt stark nach Strategie-Fachjargon. Das kann es für manche Teams schwer verkäuflich machen, die ihn als eine andere Form von Mikromanagement verstehen (und manchmal haben sie recht!).

OKRs sollten Teams stärken und Innovation von unten nach oben fördern — aber dafür braucht man die richtige Kultur. Das bedeutet, Raum dafür zu schaffen, dass Menschen es versuchen und scheitern können, und es bedeutet, in die richtigen Tools und Prozesse zu investieren, damit dein Team wachsen kann.

Jeder ist verantwortlich

„Alle arbeiten zusammen, um die Ziele auf Organisationsebene zu erreichen, anstatt zu optimieren, was für das eigene Team oder die eigene Abteilung am besten ist.“

Bei OKRs geht es in erster Linie um Ausrichtung. Das Ziel ist es, einen gemeinsamen Nordstern zu schaffen und eine gemeinsame Sprache zu definieren, um zu beschreiben, wie Erfolg aussieht.

Das ist auch der Grund, warum OKRs team- statt personenbasiert sein sollten. Es geht darum, das zu tun, was am besten für die Kunden und das Unternehmen ist, nicht das, was gut für jedes einzelne Mitglied der Organisation ist.

Was das in der Praxis bedeutet

Überprüfe den Fortschritt jede Woche

In einem normalen Continuous-Delivery-Flow würdest du wollen, dass Code jeden Tag integriert wird. Das wäre für OKRs zu viel, und ein wöchentlicher Rhythmus reicht völlig aus.

Aktualisiere den Fortschritt bei den Key Results am Montag und lass das Team sich dann während der Woche auf die Arbeit konzentrieren. Sie werden den richtigen Kontext im Kopf haben und sollten in der Lage sein, bis zum nächsten OKR-Meeting etwas zu bewegen.

Verwende Rot/Gelb/Grün-Status, um dein Vertrauensniveau anzuzeigen

Du brauchst eine einfache Möglichkeit zu erkennen, wann etwas aus dem Ruder läuft. In der Software passiert das, wenn der Build rot wird. Du kannst ähnliche Ergebnisse erzielen, indem du Ampeln verwendest, um dein Vertrauensniveau für jedes der Key Results anzuzeigen.

Achte darauf, die Historie deiner Check-ins zu behalten! Ersetze keine bestehenden Werte in deiner Tabelle, da dies verhindert, dass du Trends erkennen kannst.

Mache deine KRs messbar

Vermeide binäre Key Results (es ist ausgeliefert/nicht ausgeliefert) oder vage Aussagen (Nutzer lieben unser Produkt). Wenn du willst, dass dein Team effektiv arbeitet, brauchst du konkrete Wege, um Fortschritt zu messen.

• Es ist ausgeliefert -> Wir gehen von 0 auf 350 wöchentlich aktive Nutzer
• Nutzer lieben unser Produkt -> Wir steigern unseren NPS von 20 auf 60

3x Rot = alle Mann an Deck

Continuous Integration erfordert, dass der Build repariert wird, sobald er kaputt ist. Bei OKRs muss man etwas nachsichtiger sein, da der Fortschritt schwanken kann, aber ich empfehle, beim 3. roten Update ein ernstes Gespräch zu führen.

Es geht nicht immer darum, das Team dazu zu bringen, alles stehen und liegen zu lassen, um sich auf ein Ziel zu konzentrieren. Manchmal wirst du merken, dass du vielleicht zu ambitioniert warst oder dass es von Anfang an das falsche KR war. Aber — dieses Gespräch musst du führen, damit alle auf derselben Seite sind.

Bleib locker!

Continuous Delivery ist nur möglich, wenn das Deployen von Code in die Produktion ein Kinderspiel ist. Dasselbe gilt für das Aktualisieren der OKRs.

Wenn es sich wie eine lästige Pflicht anfühlt oder Leute Stunden brauchen, um ihre KRs zu aktualisieren, werden sie irgendwann damit aufhören. Und wenn sie aufhören, ihre KRs zu aktualisieren, werden sie sie bald vergessen. Du wärst wieder am Anfang.