Agile Organisation – Methoden, Prozesse und Strukturen im digitalen VUCA-Zeitalter

6.6 Objectives & Key Results (OKR)

Bereits in den 1950ern hat PETER DRUCKER zur Koordination der arbeitsteiligen Aufgabenerfüllung in Unternehmen das Konzept des Management by Objectives (MbO) entwickelt.

173

 Hierbei erfolgt die Koordination der von verschiedenen Menschen(gruppen) erbrachten Arbeit durch Ziele. Top-down abgeleitete, über verschiedene Hierarchieebenen hinweg kaskadierte und aufeinander abgestimmte Ziele sorgen für eine einheitliche Ausrichtung des gesamten Unternehmensgeschehens. Es ist aber – in definierten Grenzen – den die Aufgaben erfüllenden Menschen(gruppen) überlassen, wie sie diese Ziele erreichen (Selbstorganisation). Entscheidend ist, ob die Ziele erreicht werden. Daran werden Mitarbeiter und Manager gemessen.

Diese Steuerungslogik hat sich in den letzten Jahrzehnten im Management durchgesetzt und gilt auch heute nach wie vor. Über einige Jahre war dabei die Balanced Scorecard (BSC) von KAPLAN/NORTON der am weitesten verbreitete konkrete Umsetzungsansatz für ein MbO.

174

 Der Ansatz – bzw. treffender die Art, wie er in vielen Unternehmen gelebt wird bzw. wurde –, hat sich aber im Zeitverlauf z. T. als relativ träge und kompliziert gezeigt. Auch sind die Ziele häufig zu stark von oben vorgegeben.

Deswegen hat sich im Laufe der Zeit ein agilerer und stärker partizipativer Ansatz zur Steuerung von Unternehmen(sbereichen) entwickelt – Objectives & Key Results (OKR).

175

 Entwickelt wurde dieser ursprünglich ab 1971 durch ANDY GROVE bei INTEL. Weiterentwickelt wurde er dann vom ehemaligen INTEL-Praktikanten JOHN DOERR ab 1999 bei GOOGLE. In den letzten Jahren ist die Anzahl der Unternehmen, die mit diesem Ansatz arbeiten, kontinuierlich gewachsen.

176

Das zentrale OKR-Prozessmodell ist in der

Abbildung 30

 dargestellt. Ausgangspunkt sind die angestrebte Vision und die Mission bzw. der Purpose (vgl.

Kapitel 4.4

) des Unternehmens. Diese definieren die langfristige, normative Ausrichtung des Unternehmens. Sie geben allem Handeln im Unternehmen eine gemeinsame Richtung. Sie sollen kurz und knapp, aber für alle Beteiligten transparent und klar zum Ausdruck bringen, in welche generelle Richtung man gemeinsam gehen will.

Abb. 30: Prozessmodell von OKR

177

Aufgrund des langfristigen Horizonts und der oft abstrakten Formulierung von Vision und Mission, werden diese – wie auch im klassischen Management üblich – in mittelfristige Ziele (sogenannte „Mid-term Goals“ bzw. Moals) für das kommende Jahr überführt. Um die vorhandenen Kräfte sinnvoll zu bündeln, empfiehlt der OKR-Ansatz die Konzentration auf maximal drei bis vier Moals pro Jahr. Diese sollten die zentralen strategischen Themenfelder für das kommende Jahr abdecken. Moals müssen von ihrem Charakter her nicht zwingend messbar sein, sondern können auch als qualitative Ziele formuliert werden. Die Objectives & Key Results knüpfen an die Moals an.

Ein Objective (Ziel) ist ein umfassendes qualitatives Ziel, welches das Unternehmen bzw. den Unternehmensbereich in die gewünschte Richtung treiben soll (Wo will ich hin bzw. was möchte ich erreichen?). Je Organisationsebene werden nicht mehr als 4 Objectives empfohlen, um den Fokus nicht zu verlieren. Objectives haben bewusst nicht den Anspruch, dass aus ihnen direkt deutlich wird, was wirklich getan werden muss, denn dafür gibt es die Key Results.

Pro Objective sollten zwei bis maximal fünf Key Results (Schlüsselergebnisse) definiert werden. Dies sind quantitative Unterziele, die das „richtige“ Verhalten fördern sollen (Was muss ich tun, um das Ziel zu erreichen?) und anhand derer gemessen werden kann, ob ein Objective erreicht wurde oder nicht. Wie der Begriff „Results“ herausstellt, sollte es sich nicht um Aufgaben, To-Dos oder KPIs handeln, sondern Ergebniszustände. Diese sollten SMART – also spezifisch, messbar, ambitioniert, (aber) realisierbar und terminiert – und mit den Key Results von anderen Teams, mit denen es Berührungspunkte gibt, abgestimmt sein.

Abb. 31: Beispiel für OKR

Alle OKR eines Unternehmens(bereichs) werden in einer gemeinsamen OKR-Liste abgebildet. Dies geschieht jeweils zu Beginn eines OKR-Zyklus im OKR-Planning. Die OKR-Liste sollte für jeden greifbar und jederzeit einsehbar sein, denn sie dient auch dazu, mögliche Synergien oder Konflikte zwischen einzelnen OKR-Teams zu identifizieren.

Kernelement des OKR-Prozessmodells ist der 2- bis 4-monatige (meist quartalsweise) Zyklus aus OKR-Planning, -Weekly, -Review und -Retrospektive (vgl.

Abbildung 30

). Hier zeigt sich eine gewisse Ähnlichkeit zu Scrum (vgl.

Kapitel 6.3

).

Am Beginn des OKR-Zyklus steht das OKR-Planning. Dieses findet mindestens auf zwei Ebenen statt, zum einen für das gesamte Unternehmen und zum anderen auf Ebene der einzelnen Teams. Weitere Zwischenebenen sind in großen Unternehmen üblich (z. B. Geschäftsbereiche, Abteilungen, Niederlassungen). Optional können auch OKR für einzelne Mitarbeiter definiert werden. In der Planung werden die OKR für den kommenden Zyklus definiert, wobei die Unternehmens-OKR den Rahmen für die Team-OKR festlegen. Die Kernfrage des Team-OKR-Plannings sollte lauten: „Wie können wir als Team unser Unternehmen (bzw. unseren Bereich) unterstützen, seine OKR zu erreichen?“ In einem top-down und bottom-up getriebenen Abstimmungsprozess sollten Team-OKR festgelegt werden, die von dem Team selbst direkt beeinflusst werden können und auf die sich das Team gemeinsam committet. Diese stärkere Einbindung und Selbstbestimmung bei der Zielfestlegung ist ein wesentlicher Unterschied von OKR zu klassischen MbO-Ansätzen. Mögliche Unstimmigkeiten oder Doppelarbeiten zu anderen Teams sollen durch die transparente OKR-Liste offenkundig gemacht und typischerweise durch einen OKR-Master (ähnlich zum Scrum-Master) adressiert werden.

Zur wöchentlichen Synchronisation sind auf allen Ebenen kurze, ca. 15-minütige OKR-Weekly vorgesehen (ähnlich zum Daily-Scrum). Diese sollen die OKR im Bewusstsein und Fokus halten und allen ein Gefühl geben, wie der aktuelle Fortschritt ist. Dazu werden typischerweise folgende Kernfragen behandelt: 1. Wie ist der aktuelle Stand unserer OKR? 2. Gibt es weitere größere Themen außerhalb der OKR, die uns beschäftigen? 3. Gibt es Hindernisse, die uns bei der Zielerreichung stören?

Wie ein Sprint in Scrum, endet auch der OKR-Zyklus mit einer Review und einer Retrospektive – jeweils auf allen OKR-Ebenen, also mindestens Unternehmens- und Team-Level. Inhalt des OKR-Review ist der Grad der Zielerreichung und die dahinterliegenden Gründe bzw. Ursachen. Also inwieweit wurden die Objectives & Key Results erreicht, woran lag dies und was kann man daraus lernen? In der OKR-Retrospektive geht es dagegen um die Zusammenarbeit innerhalb der jeweiligen Ebene auf Basis des OKR-Ansatzes. Optimiert werden soll hier der Einsatz von und die Arbeit mit OKR.

Review und Retrospektive schließen den OKR-Zyklus ab bzw. bilden die Basis für den nächsten Zyklus, beginnend mit der Planung neuer OKR – oder, was explizit möglich ist, einem „Nachschärfen“ von Moals oder gar einem Hinterfragen von Vision und Mission/Purpose.

Im Gesamtbild zeigen sich somit etliche Parallelitäten zum Scrum-Prozess. Wer mit diesem vertraut ist, kann sich daher OKR zwar etwas vereinfacht, aber durchaus treffend als MbO-Ansatz mit Scrum-Prozesslogik vorstellen.

Es lässt sich somit festhalten, dass der Kern von OKR die klassische MbO-Denke ist. Es geht um die Koordination der Aktivitäten im Unternehmen über definierte und aufeinander abgestimmte Ziele. Wie bei anderen, klassischen Steuerungsansätzen (z. B. BSC) auch, werden Ziele definiert und die Zielerreichung wird gemessen, um auf dieser Basis „nachsteuern“ zu können. Im Detail zeigen sich jedoch einige wesentliche Unterschiede bei OKR. Zu nennen sind insbesondere die folgenden:

 Die eigentlichen Ziele (Moals und Objectives) dürfen bewusst qualitativ sein und müssen nicht konkret spezifiziert und messbar sein – z. B. wenn eine genaue Zieldefinition aufgrund der VUCA-Umwelt nicht wirklich sinnvoll ist bzw. eine Scheingenauigkeit erzeugt. Die Mess- und damit Steuerbarkeit wird über die Key Results gewährleistet.

 Die OKR sind zwar aus der Vision und Mission des Unternehmens abgeleitet, der Zielfestlegungsprozess läuft aber bewusst nicht rein top-down ab, sondern die Teammitglieder sind aufgefordert, eigene Aktivitäten und OKR für die Erreichung der übergeordneten Ziele zu definieren – als erste Orientierung eignet sich eine Aufteilung von ca. 50 % top-down und 50 % bottom-up. Diese höhere Partizipation soll für eine höhere Motivation sorgen. Es wird aber auch „anstrengender“ für die Mitarbeiter, weil mehr unternehmerisches Denken gefordert ist.

 Durch die OKR-Liste sind alle OKR im gesamten Unternehmen transparent und von jedem einsehbar. Es soll keine Hidden Agenda geben, sondern jeder soll wissen, wer welche Ziele verfolgt. Damit wird auch das Big Picture für die einzelnen Mitarbeiter leichter ersichtlich.

 Vor dem Hintergrund der VUCA-Umwelt wird der OKR-Zyklus bewusst kurzgehalten und umfasst nur ein paar Monate (meist ein Quartal). Dies ist zwar auch im BSC-Ansatz so angedacht bzw. umsetzbar, wird aber in der Praxis dann doch oft anders gelebt (insb. was die Veränderung der Ziele angeht).

 Unter anderem durch den kurzen Zyklus ist es auch möglich, mehr Fokus auf ein paar wenige strategische Themen bzw. Ziele zu legen. So soll es gelingen, „mehr Druck auf den Kessel“ zu bekommen und Themen in kürzeren Zeitfenstern fertigzustellen.

 Es geht nicht zwingend darum, alle Objectives vollständig zu erreichen. Sie sollen bewusst (über-)ambitioniert formuliert werden („stretch goals“). Es wird eine Zielerreichung von in der Regel 70-90 % angestrebt.

 Der OKR-Ansatz soll für Ausrichtung und Motivation im Unternehmen sorgen, es ist aber ganz bewusst keine Mitarbeiterbewertungsmethode. Dementsprechend sollen Zielabweichungen nicht sanktioniert werden, sondern als Daten- und Anhaltspunkte zum Lernen und zur Verbesserung dienen – ein in der Praxis nicht immer ganz so leicht umzusetzender Anspruch.

 OKR sollen dementsprechend auch nicht an ein Bonussystem gekoppelt sein, denn auch dies führt dazu, dass Ziele oft nicht ambitioniert genug definiert werden, sondern so, dass man sie auch erreicht. Ziel des Handelns soll es aber sein, das Bestmögliche für das Unternehmen zu erreichen, nicht eine irgendwann mal politisch-abgewogen definierte „(Ziel-)Latte zu überspringen“.

 Im Unternehmen sollte es verantwortliche Personen geben (oft OKR-Master genannt), welche den Ansatz aktiv vorantreiben und für die Mitarbeiter als Coach, Experte, Prozesswächter, Facilitator und Change-Agent agieren.

Wichtig ist auch die Erkenntnis, dass der OKR-Ansatz einen Rahmen liefert, innerhalb dessen es einen großen Spiel- und Gestaltungsraum gibt. Es ist möglich und gewünscht, dass die Nutzer die Methode je nach konkreter Umwelt-, Unternehmens- und Teamsituation adaptieren und gestalten. Hier steht OKR also ganz im Sinne agilen Denkens.

Und wie bei den anderen hier vorgestellten agilen Ansätzen gilt auch für OKR, dass es nicht ausreicht, einfach das agile Tool einzuführen oder die darin enthaltenen Begriffe zu nutzen, sondern die Methode lebt davon, dass auch „wirklich so gedacht“ wird. Von daher ist es sicherlich nicht sinnvoll, die Mitarbeiter mit neuen Begriffen (wie Objectives und Key Results) zu verwirren und damit dann doch ein klassisches Ziel- und Kennzahlenmanagement zu betreiben. Auch besteht durchaus die Gefahr, aus OKR ein bürokratisches System aufzubauen. Im Start-up-Umfeld wird u. a. deshalb häufig statt mit einem OKR- oder sonstigem Kennzahlensystem einfach mit wenigen Leitkennzahlen („North-Star-Metriken“) gearbeitet. Andersherum ist es durchaus möglich, am im Unternehmen bereits etablierten Steuerungssystem anzusetzen (z. B. Balanced Scorecard), die Umsetzung und Anwendung aber agiler zu gestalten.

6.7 Gemeinsamkeiten, Unterschiede und Auswahlkriterien

Im Rahmen der Darstellung der ausgewählten agilen Methoden dürfte klar geworden sein, dass diese für verschiedene Einsatzzwecke geeignet sind – und daher auch durchaus sinnvoll kombiniert werden können.

178

Design Thinking eignet sich zum systematischen Erfinden und Innovieren. Die Methode setzt sehr früh an, wenn oft das zu lösende Problem noch gar nicht richtig klar ist. Hier betont Design Thinking, dass es wichtig ist, an den Bedürfnissen und Motivationen der Menschen anzusetzen, die „am Ende” die Anwender und Nutzer der jeweiligen Ergebnisse sind. Der Ansatz bietet ein entsprechendes Instrumentarium, um die Situation, Position und Motivation der Anwender zu verstehen. Das Ergebnis sind Produktideen sowie (visuelle und haptische) Prototypen und Modelle, keine fertigen Produkte.

Auf Basis einer Produktidee und ersten Prototypen bspw. aus einem Design-Thinking-Prozess kann über die Lean-Startup-Methode und den „Bauen, Messen und Lernen“-Zyklus ein tragfähiges Geschäftsmodell entwickelt werden, indem Hypothesen zum Geschäft und „minimal funktionsfähige Produkte“ mit echten Kunden bzw. Nutzern getestet werden. Auf Basis der am realen Markt gemessenen Befunde wird gelernt, was tatsächlich funktioniert und – genauso wichtig – was nicht.

Die wirkliche Produktentwicklung und kontinuierliche Produktweiterentwicklung kann dann über die Scrum-Methode erfolgen, indem in einem iterativen Prozess immer neue bzw. optimierte Produktinkremente entwickelt werden, und jeweils Feedback dazu eingeholt wird. So gelangt man Stück für Stück zu einem immer besser zu den tatsächlichen Kundenbedürfnissen passenden (fertigen) Produkt.

Zum agilen Agieren in einem gegebenen Prozess – bspw. bei der Produktion des vorher über die anderen dargestellten agilen Methoden entwickelten Produkts – eignet sich dann der Kanban-Ansatz. Dieser hilft dabei, „vor Ort“ auf Schwankungen bzw. Planabweichungen an verschiedenen Stellen im System zu reagieren. An die Stelle einer sehr komplexen, verschachtelten, aufwendigen Zentralsteuerung treten dezentrale, selbstregelnde, autonome Regelkreise. Die primäre Steuerung wandert von der zentralen Planungseinheit zum letzten Glied der Prozesskette (Pull-Prinzip). Dadurch wird eine kontinuierliche Verbesserung unterstützt.

Diese vier agilen Methoden kann man sich also in einer gewissen zeitlichen Logik vorstellen. Quer bzw. ergänzend dazu – aber auch in anderen Kontexten – bietet der „Objectives & Key Results“-Ansatz ein Steuerungskonzept. OKR liefert einen agilen „Management by Objectives“-Ansatz, der im Hinblick auf den Ablauf einige Parallelitäten zum Scrum-Prozess aufweist. Die Methode hilft dabei, verschiedene Aktivitäten in einem Unternehmen(sbereich) auf gemeinsame Ziele auszurichten, ohne dadurch zu viel an Freiraum und Flexibilität zu nehmen.

Natürlich gibt es neben den hier aufgeführten Prozess- und Projektmanagementansätzen noch viele weitere agile Methoden. Zu nennen sind bspw. der im Beitrag von MAURER in diesem Buch beschriebene Effectuation-Ansatz zur agilen Planung oder die im Beitrag von SCHULLER/FUCKER, HEILER/BORCK und TILLMANNS-ESTORF/​GROßE/GUMULA vorgestellten Entscheidungsansätze.

179

 Darüber hinaus gibt es eine unüberschaubare Anzahl an kleinen Veränderungen im Arbeitsalltag (sogenannte Workhacks bzw. Nudges), die ein agileres Handeln anstoßen und dadurch letztlich ein agiles Denken unterstützen.

180

Neben diesen Unterschieden beim Einsatzzweck der verschiedenen Methoden zeigen sich auch im Anwendungsprozess ein paar Unterschiede bzw. unterschiedliche Schwerpunkte. Die folgende

Abbildung 32

 gibt einen groben (weil verkürzten) Eindruck über den jeweiligen Fokus bzw. zentrale Kernaspekte der Methoden.

Abb. 32: Fokus und gemeinsamer Kern verschiedener agiler Methoden (vereinfacht)

181

Die Abbildung weist aber auch bewusst einen gemeinsamen Kern auf. Denn aus der Darstellung der Methoden sollte auch klargeworden sein, dass Kanban, Scrum, Lean Startup, Design Thinking und OKR in der Denke etliche Gemeinsamkeiten aufweisen. Alle diese agilen Ansätze teilen eine gemeinsame Denkweise und Handlungslogik (Agile Mindset, vgl.

Kapitel 2.2

). Folgende Kernelemente der agilen Organisation (vgl.

Kapitel 4

) tauchen in den Darstellungen der Methoden wiederholt auf:

 Kundenzentrierung (intensive Auseinandersetzung, regelmäßiger Abgleich)

 Iterativ-inkrementelles Vorgehen (Sprints, Hypothesen, Experimente, Prototypenbau)

 Integrierte Feedback- und Lernschleifen (Reviews, Retrospektiven)

 Fokussierung (Zeit- und Mengenbegrenzungen über Time-Boxing, Work-in-Progress-Limits)

 Autonome, cross-funktionale Teams (mit intensiver Interaktion auf Augenhöhe)

 Selbstorganisation mit Pull-Prinzip (in den Teams)

 Transparenz (Boards, Backlogs)

 Definierte Abstimmungs- und Entscheidungsprozesse (Dailys, Review Meetings).

Diese Grundgedanken gilt es ins Unternehmen zu holen – mit welchem Ansatz auch immer. Es ist sowohl möglich, nur einzelne Teilaspekte der Ansätze herauszugreifen, als auch die vers