Skalierte Agilität – Transformation und Innovation mit OKRs steuern (I)
Komplexe Softwaresysteme für große Unternehmen wirklich agil zu entwickeln, stellt uns vor Herausforderungen auf vielen Ebenen: kulturell, organisatorisch, finanziell, infrastrukturell oder architektonisch. In unserer Artikelserie betrachten wir verschiedene Probleme der skalierten Agilität aus ganzheitlicher Unternehmenssicht und versuchen, praktische Verbesserungsvorschläge zu geben.
Objectives and Key Results - kurz OKRs - sind in aller Munde. In diesem Teil I schärfen wir das Konzept durch Abgrenzung zu verwandten Ideen und beschreiben, wo und wie OKRs in agilen Organisationen für nachhaltige Transformation und Innovation effektiv genutzt werden können - und das mit der notwendigen Verbindlichkeit.
Mit OKRs ins Tun kommen
Datenkompetenz im Unternehmen leben: Dedizierte Ziele setzen, diese objektivierbar machen und dann nachverfolgen. So könnte man Objectives and Key Results (OKRs) auf den Punkt bringen. Ganz allgemein gesprochen, versteht man unter OKRs eine Methodik zur Zielerreichung. Über OKRs werden strategisch eingebettete Geschäftsziele (Business Outcomes) quantifizierbar, so dass der Fortschritt hin zu diesem Zielen klar zu sehen ist.
(Quelle: Eigene Darstellung/metafinanz)
Wie funktionieren OKRs?
Ein OKR besteht aus einem spezifischen, messbaren, zeitgebundenen, aber durchaus ambitionierten Ziel, sowie einer oder mehreren Metriken (Key Results), die den Fortschritt in Richtung Zielerreichung zu definierten Zeitpunkten messen. Im Kontext der skalierten Agilität können OKRs für Ziele auf verschiedenen Ebenen der Organisation und deren wechselseitiger Abstimmung verwendet werden. Dabei kann es sich um herausfordernde unternehmensweite strategische Ziele handeln wie zum Beispiel: „Wir wollen bis Ende nächsten Jahres einen Marktanteil von 35 Prozent bei On-Demand-Versicherungen in Europa erreicht haben.“ Aber es sind auch eher kurzfristige produktbezogene Ziele möglich, etwa: „Wir wollen jeden Monat eine Steigerung der Benutzerloyalität (Come-Back-Rate) um zehn Prozent sehen.“
Auch lassen sich transformatorische Ziele im Hinblick auf die Veränderung der eigenen Organisation sehr gut in OKRs ausdrücken: „Innerhalb von zwei Jahren möchten wir zu Deutschlands Top-Arbeitgeber für junge Talente avanciert sein.“
Aber zu OKRs im agilen Kontext gibt es noch mehr zu sagen – und darum geht es in unserem zweiteiligen Artikel:
- Wie hängen OKRs auf verschiedenen Ebenen zusammen?
- Wer definiert sie, und wann sollten überambitionierte Ziele korrigiert werden?
- Wie können OKRs zur Bewertung von Minimum Viable Products (MVPs) verwendet werden?
- Können OKRs (agile) Roadmaps ersetzen?
Schließlich – und das sind vermutlich die am häufigsten gestellten Fragen an uns: Wie kann das Management sicherstellen, dass OKRs auch tatsächlich in den Teams umgesetzt werden? Welche Rolle spielen OKR-Tools dabei? Und brauchen wir sie, um eine OKR-Kultur zu etablieren?
Geschichte der OKRs in 30 Sekunden
OKRs wurden erstmals vom ehemaligen Intel-Mitbegründer und CEO Andy Grove in seinem 1983 veröffentlichten Buch „High Output Management“ eingeführt. Weithin bekannt wurden OKRs, als Google das Framework Anfang der 2000er Jahre übernahm, um die Produktivität und Verantwortlichkeit zu verbessern. Google begann 1999 mit der Verwendung von OKRs, als das Unternehmen aus 40 Mitarbeiterinnen und Mitarbeitern bestand, und nutzt sie bis heute mit rund 190.000 Angestellten. Die Botschaft ist klar: OKRs können von Organisationen jeder Größe verwendet werden.
Um die wahre Natur von OKRs besser zu verstehen, kann es hilfreich sein, sich anzusehen, was OKRs nicht sind.
OKR ist kein MBO (Management by Objectives)
Beim MBO werden vermeintlich objektivierbare und messbare jährliche Einzel- oder Teamziele im Dialog zwischen Vorgesetztem und Mitarbeiter festgelegt, kaskadierend von oben nach unten. Auch bei OKRs gibt es unterschiedliche Ebenen, von strategisch-übergeordnet bis spezifisch-operativ. Die Koordination ist jedoch bidirektional, mit mehr Autonomie und Entscheidungsbefugnis im jeweiligen Kontext, und das Ziel kann (und sollte) im Laufe der Zeit überarbeitet werden, wenn sich die Bedingungen ändern. Typischerweise werden OKRs alle zwei bis vier Monate einem Review unterzogen.
Der entscheidende Unterschied ist jedoch, dass OKRs eine treibende, visionäre Kraft entfalten sollen. Sie fokussieren sich auch stärker auf den Prozess der Zielerreichung, indem sie Metriken (Key Results) definieren. Ein Ziel kann und sollte (über)ehrgeizig formuliert werden, und wenn es nicht erreicht wird, gibt es keine Gehaltseinbußen oder andere disziplinarische Konsequenzen.
OKRs sind keine KPIs (Key Performance Indicators)
Beide messen die Leistung. Während sich OKRs auf wenige Schlüsselziele („Weniger ist mehr“) und eine strategische Richtung in Bezug auf das Geschäftsergebnis konzentrieren, werden KPIs eher für generische Standardziele und dafür verwendet, den Status und Zustand eines Systems (z. B. Control Tower oder DevOps-Pipeline) operativ zu messen und zu überprüfen.
OKR ist nicht BSC (Balanced Score Card)
Im Gegensatz zu OKR, das sich auf bestimmte Ziele konzentriert, ist BSC ein ganzheitlicheres Management-Framework, das die Leistung eines Unternehmens aus vier übergeordneten Schlüsselperspektiven (Finanzen, Kunden, interne Prozesse, Lernen und Wachstum) betrachtet und für aus diesen ergebnisorientierte Ziele ableitet.
OKR ist nicht PI Objectives (Program Increment Objectives)
PI Objectives dienen der verbindlichen Vereinbarung zwischen Business und Team zur Umsetzung konkreter Liefergegenstände (Outputs). OKRs hingegen setzen ehrgeizige Ergebnisziele.
Ausblick auf Teil II
In Teil II stellen wir unser erweitertes OKR-Schema vor, das Unternehmen hilft, qualitativ hochwertige OKRs für unterschiedliche Kontexte zu definieren und in moderne agile Steuerungswerkzeuge zu integrieren.
Co-Autor: Stefan Hanslmaier (Allianz – XING)
Quelle Titelbild: AdobeStock/pixelbliss
