On Lean and Agility

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) einfach. Man setzt ein abstraktes, mittelfristiges Objective (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen messbaren Key Results (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Eine Herausforderung, die dadurch entsteht ist aber die Verbindung der OKRs mit der übergreifenden Unternehmensstrategie.

Um klarer zu machen warum das eine Herausforderung ist: eine übergreifende Strategie setzt sich zusammen aus Entscheidungen, auf welche Märkte, Produkte, Preissegmente und Produktionsprozesse sich ein Unternehmen in der länger- und langfristigen Zukunft konzentrieren will, was in der Regel einen Zeithorizont von Jahren oder sogar Jahrzehnten bedeutet. Zwischen einer solchen auf Jahre ausgerichteten Strategie und den nur wenige Monate umfassenden OKR-Zyklen klafft eine Lücke.

Versucht man diese Lücke zu schliessen entsteht die nächste Herausforderung: so wie OKRs gedacht sind, sollten die Objectives keine bereits lange im Voraus festestehenden Teile eines Work Breakdown aus einem Strategie-Umsetzungsplan sein, sondern noch kurz vor jedem Zyklus verfasst oder angepasst werden können. Das Ziel sollte also sein, eine Verbindung zwischen Strategie und OKRs zu schaffen, die zwar für eine übergreifende Ausrichtung sorgt, dabei aber möglichst wenig einengend ist.

Wie das im Einzelfall aussehen kann hängt vom jeweiligen Kontext ab. Wenn der z.B. eher von Product Discovery geprägt ist, also von einer Neu- oder Weiterentwicklung mit schnellen Feedback-Zyklen, kann es Sinn machen, Outcome-orientierte längerfristige Ziele zu formulieren (z.B. "langfristige Power User werden für ihre Treue belohnt"), ohne vorzugeben, durch welche Massnahmen, mit welcher Belohnung oder oder in welchen Systemen das erreicht werden soll.

Wenn es dagehen eher um die kontinuierliche Optimierung etablierter Produkte oder Services geht, kann es ein guter Weg sein, North Star-Metriken zu definieren (z.B. je nach Produkt Anzahl der Buchungen, Interaktionsraten, Nutzungsdauern, etc) und deren dauerhafte und langfristige Optimierung anzustreben, auch hier ohne eine länger im Voraus verfasste Vorgabe, wie das stattzufinden hat. Und natürlich gibt es neben diesen beiden Kontexten noch viele weitere mögliche.

Da es auch im Umfeld der OKRs zur Entwicklung einer eigenen Fachsprache gekommen ist, gibt es auch für diese Verbindungselemente zwischen Strategie und Objectives einen eigenständigen Namen. Man spricht von "Moals",  wobei es sich um eine Abkürzung für "mid-term Goals" handelt, also um mittelfristige Ziele im Sinn von Jahreszielen, o.Ä. Wie immer im Fall solcher Begriffe kann man sich auch bei diesem über Sinnhaftigkeit und Originalität streiten, zumindest ist er aber OKR-spezifisch.

Ob man den Begriff benutzt oder nicht ist am Ende auch relativ egal, viel wichtiger ist, dass die Lücke zwischen Strategie und OKRs überhaupt geschlossen wird. Und eine letzte wichtige Faustregel kann man sich merken: immer wenn versucht wird, Prozesse und Formate rund um diese Verbindungsschicht vorzugeben (formalisierte Moal Plannings, zu befogende Moal Templates, etc) hat das nicht mehr viel mit der ursprünglichen Idee der OKRs zu tun, sondern ist Teil des agil-industriellen Komplexes.

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) erstmal einfach. Man setzt ein abstraktes, mittelfristiges Ziel (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen konkreten, messbaren Ergebnissen (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Die Herausforderung, die dadurch entsteht ist aber: wie lässt sich das mit dem Alltagsgeschäft verbinden?

Die erste und naheliegende Antwort ist es, in kurzen Abständen (z.B. wöchentlich) zu überprüfen, ob Forschritt in der gewünschten Richtung stattfindet und ggf. Anpassungsmassnahmen zu beschiessen, falls die bisherigen Ergebnisse zu wünschen übriglassen. Auch hier bleibt aber offen, was genau es ist, das da begutachtet wird. Natürlich kann man sich immer wieder die OKRs selbst vorlegen, die Verbindung zum Alltagsgeschäft wäre damit aber noch immer nicht gegeben.

Ein häufig anzutreffender Ansatz zum Schliessen dieser Lücke ist, für die jeweiligen Key Results einen weiteren Work Breakdown durchzuführen und die Umsetzung der sich so ergebenden Arbeitspakete mit Hilfe eines Backlogs oder einer Roadmap zu planen.¹ Damit wird nicht nur die Umsetzungslücke geschlossen, es ist darüber hinaus möglich, die OKR-Aufwände und die sonstigen Tätigkeiten in einer gemeinsamen Planungssicht zusammenzufassen und so Redundanzen und Überplanung zu vermeiden.

Die Art der jeweiligen Arbeitspakete kann schliesslich variieren. Sie können die Bereitstellung der (Infra-)Strukturen zum Gegenstand haben, die für die Erbringung von Leistungen Voraussetzung sind, sie können aus der Fertig- und Bereitstellung von neuen Produkten, Features oder Services bestehen, sie können aber auch die Form von Business-Experimenten haben, durch die erforscht wird, auf welche Art und Weise sich Nutzergewohnheiten ändern oder Kaufanreize setzen lassen.

Wichtig bei der Definition dieses Unterbaus unterhalb der OKRs ist dabei weniger, um was für Arbeitspakete es sich genau handelt, sondern eher ob sie zur Erreichung der übergeordneten messbaren Ergebnisse, der Key Results, beitragen. Stellt sich heraus, dass sie einen Beitrag leisten, sollten sie ggf. wiederholt und intensiviert werden können, leisten sie keinen erkennbaren Beitrag muss es möglich sein, sie unbürokratisch zu variieren oder zu verwerfen. Auf keinen Fall dürfen sie zum Selbstzweck werden.

Der Vollständigkeit halber sei noch erwähnt, dass diese Art mit Objectives and Key Results zu arbeiten weder die einzige ist, noch eine die per Definition besser als andere Vorgehensweisen wäre. Es ist aber eine, mit der sich die Verbindung zwischen OKRs und Alltagsgeschäft gut herstellen lässt. Wer in diesem Bereich Verbesserungspotential sieht, kann daher einen Versuch wagen und überprüfen, wie gut dieser Ansatz für ihn funktioniert - idealerweise anhand von im voraus definierten Erfolgskriterien.

Was man beim Ansehen des Videos im Hinterkopf behalten sollte: es gibt nicht die eine richtige Art OKRs zu verfassen, sondern viele verschiedene Varianten, die parallel nebeneinander koexistieren (siehe hier). Gothelf und Seiden haben starke (und fundierte) Meinungen, und das was sie sagen dürfte dem State of the Art entsprechen. Andere Umsetzungen sind aber nicht falsch - nur anders.

Sobald ein agiles Framework ein gewisses Alter überschritten hat, entstehen in der Regel nach und nach verschiedene Varianten, die anfangs noch aufeinander aufbauen, später aber parallel zueinander existieren. Das ist bei Scrum und bei Kanban so gewesen, und es ist auch bei Objectives und Key Results (OKR) so. Da die neueren OKR-Varianten sich z.T. zu erstaunlich schwerfälligen Prozessframeworks entwickelt haben, lohnt ein Blick zurück - denn eigentlich ist es ursprünglich anders gedacht gewesen.

Wie immer bei derartigen Übersichten ist auch diese hier subjektiv, sie umfasst aber meiner Meinung nach die wichtigsten Spielarten und Entwicklungsstufen, bzw. die wichtigsten Vordenker. In der Realität dürften darüber hinaus noch zahlreiche Abwandlungen und Mischtypen anzutreffen sein, diese Liste hier dürfte aber die relevanten umfassen (wenn ich etwas übersehen haben sollte, freue ich mich über einen Hinweis, der hier abgegeben werden kann). Aber zur Sache, hier sind die Evolutionsstufen:

MBOSC (Management by Objectives and Self-Control)

Eine Früh- oder Vor-Version der heutigen OKRs, beschrieben in den 50er Jahren von Peter Drucker in seinem Buch The Practice of Management. Mit dezentraler Planung, Trennung von abstrakten Zielen und konkreten Ergebnissen und mit Zyklen von weniger als einem Jahr waren die Grundzüge der heutigen Praktiken bereits enthalten. Unter dem Namen Management by Objectives (MBO) wurde Druckers Ansatz leider später zu einem jährlichen Kontroll- und Budgetierungsinstrument verfremdet (siehe hier).

Ursprüngliche OKRs (Intel MBOs)

Die Ursprungsversion, entwickelt in den 70er Jahren von Intel-CEO Andy Grove und beschrieben in seinem Buch High Output Management. Grove definierte neben den abstrakten Zielen (Objectives), den konkreten Ergebnissen (Key Results) und den kurzen Zyklen (maximal ein Jahr) kaum Vorgaben zur Umsetzung, entwickelte aber schon die Idee "kaskadierender Objectives", die auf den unteren Hierarchie-Ebenen in Teilziele heruntergebrochen werden, und von denen jede eigene Key Results hat.

"Die" OKRs (Google OKRs)

Die Variante, die berühmt geworden ist. Der ehemalige Intel-Mitarbeiter John Doerr führte die OKRs bei Google ein, wo sie um weitere Teile ergänzt wurden, u.a. um die Begrenzung des Zyklus auf ein Quartal, um die Differenzierung in "committed" und "aspirational OKRs", die Einführung gemeinsamer OKRs für mehrere Teams und um eine nachträgliche Bewertung in Ampelfarben. Das von vielen anderen Firmen kopierte Google OKR Playbook findet sich abgedruckt in Doerrs Buch Measure What Matters.¹

Silicon Valley OKRs

Die verschiedenen Unternehmen des Silicon Valley, die als erste den OKR-Ansatz von Google übernommenen haben, haben ihn mit der Zeit ebenfalls weiterentwickelt. Die bekanntesten Praktiken findet man zusammengefasst in Cristina Wodkes Buch Radical Focus, zu ihnen gehört u.a. die Beschränkung auf nur ein einziges, nach Möglichkeit firmenweites Objective pro Zyklus,² die dezentrale Erarbeitung der Key Results durch die Teams und die Einführung regelmässiger OKR-Meetings.

Scrumifizierte OKRs

Wer auf die Idee gekommen ist, die OKR-Meetings analog zu denen aus Scrum zu organisieren, lässt sich vermutlich nicht mehr feststellen, aber er hat einen Trend gesetzt. OKR-Plannings, OKR-Dailies/Weeklies, OKR-Reviews und OKR-Retrospektiven sind mittlerweile weit verbreitet, und für die Organisation und Moderation dieser Termine gibt es einen an den Scrum Master oder Agile Coach angelehnten OKR Master oder OKR Coach.³

Agile Industrial Complex OKRs

Dass angessichts dieser Geschichte einer immer stärkeren Formalisierung auch das Kommerzialisierungs-Potential gestiegen ist, dürfte wenig überraschen. Der agil-industrielle Komplex hat seit ca 2020 auch die OKR-Idee mit weiteren Regeln, Rollen, Formulierungs-Templates, prozessunterstützender Software und Ähnlichem überflutet, die dann in den Trainings und Zertifizierungsprüfungen auftauchen können. Genau wie im Fall von Scrum und Kanban übrigens mit teuren aber meistens überschaubaren Ergebnissen.

Gerade vor dem Hintergrund dieser letzten "Evolutionsstufe" ist es nicht verwunderlich, dass OKRs vor allem in grossen Organisationen eher als Management-Mode wahrgenommen werden und weniger als etwas Sinnvolles. In derartigen Fällen können die hier verlinkten Grundlagen-Bücher gegebenenfalls Klarheit bringen. Aus ihnen lässt sich erkennen, was der eigentliche Kern der Idee ist, und bei was es sich um Overhead handelt, der auch weggelassen werden kann.

Zu den grossen "agilen Trends" der letzten Jahre gehören die Objectives and Key Results (OKRs), eine Methode um persönliche oder übergreifende Ziele, von der man sich einen einfacheren oder besseren Weg zur Agilität erhofft. Die damit erzielten Ergebnisse schwanken allerdings stark, von deutlichen Verbesserungen bis deutlichen Verschlechterungen ist alles dabei. Meine steile These dazu: man kann absehen was davon der Fall sein wird, und dafür muss man nur betrachten wie vorher mit einem anderen Ansatz umgegangen worden ist - dem Management by Objectives (MBO).

Bevor wir darauf eingehen eine kurze Begriffsbestimmung. OKRs wurden von Andrew Grove bei Intel entwickelt und von seinem damaligen Mitarbeiter John Doerr später bei Google eingeführt und dadurch popularisiert. Sie teilen Ziele in qualitative Objectives und quantitative Key Results auf, von denen die ersten abstrakt-übergreifend und die zweiten davon abgeleitet und konkret überprüfbar sind. In der Umsetzung werden Objectives quartalsweise gesetzt und durch Key Results nach und nach erreicht.

Dass dieser Ansatz flexibler (und agiler?) als die sonst üblichen starren Jahresziele ist, liegt auf der Hand, und tatsächlich ist er als bewusste Weiterentwicklung, bzw. Ablösung eines Vorgehensmodells entwickelt worden, mit dem diese in den meisten Fällen umgesetzt werden, eben dem MBO. Grove und Doerr weisen in ihren Büchern High Output Management (Grove, 1983) und Measure what Matters (Doerr, 2017) explizit auf diese Art der Entstehung hin.

[Before the introduction of OKRs], goals were centrally planned and sluggishly trickled down the hierarchy. At others, they became stagnant for lack of frequent updating; or trapped and obscured in silos; or reduced to key performance indicators (KPIs), numbers without soul or context. Most deadly of all, MBOs were commonly tied to salaries and bonuses.

John Doerr: Measure What Matters, S.25

Besonders der letzte Punkt ist dabei erwähnenswert, da er den durch ihre Langfristigkeit immer realitätsferner werdenden MBOs eine destruktive Dynamik hinzufügt: die Koppelung der Zielerreichung an Gehaltsbestandteile. Es ist eine menschliche, bzw. betriebswirtschaftliche Reaktion - um den vollen Bonus ausgezahlt zu bekommen, werden alle Ziele konsequent umgesetzt, und zwar auch dann wenn sie mittlerweile als unsinnig erkannt wurden. Geld sticht Sinn.

Die Rollen sind damit klar verteilt. Alt und neu, überkommen und modern, starr und flexibel, Objectives and Key Results und Management by Objectives. Wie fast immer bei derartig klaren Gegensätzen gilt aber auch hier, dass sie zu einfach sind um wahr zu sein. Betrachtet man das Buch in dem die MBOs erstmals beschrieben wurden, The Practice of Management, geschrieben 1954 vom österreichisch-amerikanischen Ökonomen Peter Drucker, entdeckt man Erstaunliches.

The most effective managers I know [...] have each of their subordinates write a “manager’s letter” twice a year. In this letter to his superior, each manager first defines the objectives of his superior’s job and of his own job as he sees them. He then sets down the performance standards which he believes are being applied to him. Next, he lists the things he must do himself to attain these goals—and the things within his own unit he considers the major obstacles. He lists the things his superior and the company do that help him and the things that hamper him. Finally, he outlines what he proposes to do during the next year to reach his goals.

Peter Drucker: The Practice of Management, S. 343

Mit anderen Worten: das was OKRs ausmacht und es angeblich von den MBOs unterscheidet ist in diesen bereits enthalten. Die dezentrale Planung, die Trennung von Zielen und Ergebnissen, die Möglichkeit zu Anpassungen während des Jahres, all das war von Drucker bereits so angedacht. Und selbst die durch die Knüpfung an Gehaltsbestandteile durchgeführte Steuerung von oben war nicht in seinem Sinn, stattdessen spach er bewusst von Management by Objectives and Self-Control.

Reports and procedures should be the tool of the man who fills them out. They must never themselves become the measure of his performance.

Peter Drucker: The Practice of Management, S. 359

Die Betrachtung des MBO wird damit komplett auf den Kopf gestellt - nicht der Ansatz selbst ist problematisch, sondern seine falsche Umsetzung, nicht er selbst beinhaltet Top Down-Management, fehlende Flexibilität und nicht zielführende Anreizgebung, sondern die Menschen die ihn umsetzen bringen diese Ideen mit und überschreiben damit die in ihrem Ursprung komplett in die andere Richtung orientierten Umsetzungs-Empfehlungen.

Und damit kommen wir zurück zur Eingangs-These: will man voraussagen können wie eine Organisation mit Objectives and Key Results klarkommen wird, muss man eigentlich nur überprüfen wie sie mit Management by Objectives umgeht. Setzt sie dieses wie ursprünglich gedacht ein, werden auch OKRs gut funktionieren, verfremdet sie es bis in ihr Gegenteil wird sie das mit grosser Wahrscheinlichkeit auch mit OKRs tun. Da so ziemlich jede halbwegs grosse Firma bewusst oder unbewusst mit MBO arbeitet, ist das eine erstaunlich effektive Art der Überprüfung.