Ben Kölbl & Björn Schotte 17. Juni 2020

Alles OKR oder was? Zielsysteme im Agilen

Bei OKR handelt es sich um ein Management-Framework, das als Werkzeug benutzt werden kann, um strategische Unternehmensziele zu erreichen. © Adobe: Olivier Le Moal / stock.adobe.com / 42425262 — © Adobe: Olivier Le Moal

Wie kann gutes und zielorientiertes Arbeiten gelingen? Noch dazu in einer agilen Umgebung? Erinnern wir uns: In agilen Systemen sollen Teams autonom arbeiten können und eine Ende-zu-Ende-Verantwortung für das Produkt oder einen Teil davon tragen. Doch wie schaffen wir es, diese Teams und letztlich auch die Organisation auf ein oder mehrere Ziele auszurichten? In diesem Artikel wollen wir uns nicht nur den aktuellen Hype – OKR – näher anschauen, sondern auch mal einen Blick darauf werfen, welche Zielsysteme es im Agilen sonst noch gibt.

Ursprünge klassischer Zielsysteme

"Plans are worthless, but planning is everything". Dieses Zitat stammt von Dwight D. Eisenhower, dem 34. Präsidenten der Vereinigten Staaten von Amerika, der seine Karriere in der Armee begonnen hat. Was im Kern dieses Zitats steckt, wird im Laufe dieses Artikel auch noch an vielen anderen Stellen klar werden. Als Eisenhower 1957, also vor mehr als 60 Jahren, diesen oft zitierten Satz in seiner Rede verwendete, war wohl niemanden klar, wie gut er damals schon den Nagel auf den Kopf getroffen hat. Und das in einer Zeit, die außerhalb des Militärs noch deutlich entschleunigter war. 60 Jahre später, in Zeiten immer stärkerer Dynamik in Bezug auf Märkte und Kundenverhalten, ist das Planen wichtiger denn je. Die Zeit der langfristigen, starren und unbeweglichen Pläne ist aber längst Geschichte. Denn jeder Plan, egal wie gut und langfristig er auch geschmiedet wurde, löst sich, sobald er mit der Realität in Kontakt tritt, unvermeidbar in das auf, was er ist – eine Wette in die Zukunft, bei der mit zunehmender Komplexität die Gewinnchancen schwinden. Diese Tatsache lässt sich auf nahezu alle Bereiche einer Organisation anwenden und Zielsysteme stellen hier keine Ausnahme dar.

Als Pionier der modernen Managementlehre gilt der US-amerikanischer Ökonom Peter Drucker (1909 in Wien geboren). Bereits 1954 formulierte er das "Management by Objectives" (MbO) oder "Führen durch Zielvereinbarung" [1], das heute eines der weit verbreitetsten Methoden aus der Betriebswirtschaftslehre zur Mitarbeiterführung und Entwicklung von Eigeninitiative ist. Aber ist MbO unter Berücksichtigung der heute vorherrschenden dynamischen Marktbedingungen noch zeitgemäß? Um diese Frage beantworten zu können, gehen wir auf die Grundprinzipien von MbO ein. Diese sind:

MbO dient der strategischen Umsetzung sowohl der Unternehmensziele als auch der Mitarbeiterziele.
Die Summe der Einzelziele entspricht dem Gesamtziel des Unternehmens.
MbO ist ein Werkzeug zur Mitarbeiterbeurteilung durch Vorgesetzte.

Schwierigkeiten von MbO

Legt man nun diese Grundprinzipien auf ein modern organisiertes Unternehmen, dürften hier einige Reibungspunkte entstehen, insbesondere im Kontext einer Agilen Organisation und der damit ausgeprägten kulturellen Werte.

Reibungspunkte entstehen dabei in diesen Bereichen:

Es stellt sich als enorm aufwändig dar, Ziele (Unternehmen und Mitarbeiter) zu durchdenken, durchzudiskutieren, zu planen, abzuschätzen sowie zu präzisieren. Denn am Ende müssen realistische und umsetzbare Ziele für alle Mitarbeiter stehen und getragen werden.
Das führt sowohl bei den Führungskräften als auch bei den Mitarbeitern zu einem enormen Zeit- und Verwaltungsaufwand.
Bei den Mitarbeitern entsteht der Eindruck, diese Ziele zusätzlich zu der täglichen Arbeit bewältigen zu müssen.
Der Fokus einer Organisation geht auf Grund der Menge der Einzelziele verloren.
Ziele werden autoritär aufgeprägt.
Ziele dienen nicht als Mittel der Selbst-Steuerung durch den Mitarbeiter, sondern sind Mittel zur Kontrolle und Beurteilung des Mitarbeiter durch den Vorgesetzten.
Die Verknüpfung mit individuellen monetären Boni sorgt dafür, dass vorrangig die eigenen und persönlichen Interessen adressiert werden.

SMARTe Kriterien

Quasi on top müssen die Ziele zusätzlich noch in das SMART-Akronym (Specific Measurable Achievable Reasonable Time Bound) – also spezifisch, messbar, attraktiv, realistisch und terminiert – passen. Denn bei Geld hört die Freundschaft – hier die Mitarbeiterzufriedenheit – auf. Ohne SMART keine Messung, und ohne Messung keine Boni.

Klassische Zielsysteme wie MbO bringen per se immer einen gewissen Grad an Mitarbeiterzufriedenheit mit. Aber wie weit helfen sie wirklich, die Unternehmensziele zu unterstützen? Wir gehen in den folgenden Kapiteln auf diese Frage noch genauer ein.

Warum braucht es (heute) Ziele und Zielsysteme?

Nun wäre der erste Reflex, einfach kein Zielsystem zu nutzen. Wenn Zielsysteme per se die Mitarbeiter unzufriedener machen, und es meinem Unternehmen kaum hilft, die Unternehmensziele zu erreichen, warum dann das alles?

Komplexität & Dynamik

Weil Herr Eisenhower über die Jahre recht behalten hatte. Die Planung ist wichtiger denn je – nur die Art, wie wir planen, hat sich grundlegend verändert.

Das hat wie anfangs erwähnt mit dem Wandel der Welt, insbesondere der Märkte in Bezug auf Komplexität und Dynamik, zu tun. So waren in den 50er Jahren Komplexität und Dynamik in den meisten Branchen die Ausnahme. Kundenverhalten war vorhersehbar, die Konkurrenz überschaubar und meist lokal. Veränderungen wurden in Dekaden gedacht. Das Militär stellte hier eine seltene Ausnahme dar. Dreht man nun die Uhr 60 Jahre nach vorne, ist die Ausnahme inzwischen die Regel oder vielmehr die Realität geworden. Unternehmen können es sich nicht mehr erlauben, Produkte in Jahrzehnten zu planen. Kunden wechseln bei der kleinsten Unzufriedenheit einfach zur Konkurrenz, die inzwischen auch international ist. Und wer versucht, ein neues Produkt auf den Markt zu bringen, ohne zuvor akribisch seine Kundenzielgruppe analysiert zu haben, wird spätestens nach dem ersten Release von der Realität und echtem Kundenverhalten eingeholt werden. Wie kann ein Zielsystem also als Werkzeug verwendet werden, um mit diesen neuen und veränderten Marktbedingungen Schritt halten zu können?

Fokussierung

Ein Kernaspekt, der die agilen Zielsysteme von den klassischen unterscheidet, ist die Fokussierung. Und zwar eine Fokussierung auf einem im agilen Kontext sinnvollen Zeithorizont. So macht es wenig Sinn, sich für ein komplettes Jahr auf einen bestimmten Bereich zu fokussieren, wenn im Vorfeld fraglich ist, ob die Rahmenbedingungen den Zeithorizont überdauern. Eine Fokussierung auf einen oder wenige Bereiche ist aber unbedingt empfehlenswert. Nur durch eine klare und zeitlich begrenzte Fokussierung ist die Erreichung des Ziel überhaupt erst möglich. Ohne Fokussierung ist die Gefahr, sich ausschließlich vom Tagesgeschäft lenken zu lassen und in ein reines Reagieren auf Probleme zu verfallen, sehr groß. Die Fokussierung ermöglicht erst den Perspektivenwechsel. Weg vom Getriebenen, hin zum Navigator mit Kurs auf das gesetzte Ziel.

Ausrichtung (Alignment)

Fokussierung ist ein wichtiger Kernaspekt. Aber nur in Kombination mit einer gemeinsamen Ausrichtung wird aus dem vagen Plan ein mächtiges Werkzeug. Wie oben erwähnt, vertritt Drucker die These, dass die Summe der Einzelziele dem Gesamtziel des Unternehmens entspricht.

Deckt sich diese Annahme mit der Realität in Organisationen, die mit klassischen Mitarbeiterzielen arbeiten? Denn diese Mitarbeiter bekommen gar nicht die Möglichkeit, ihre persönlichen Ziele mit denen anderer abzugleichen. Warum sollten sie auch? Den Bonus bei Zielerreichung gibt es ausschließlich für die Erfüllung der eigenen Ziele. Wenn zur Erfüllung der eigenen Ziele – quasi als negativem Seiteneffekt – die Zielerreichung von anderen Kollegen erschwert oder sogar blockiert wird, nimmt man das eben in Kauf. Oft geschieht dies gar nicht bewusst, sondern ist der Tatsache geschuldet, dass ein Abgleich der Mitarbeiterziele nicht vorgesehen ist, und man schlicht davon ausgeht, dass es keine Konflikte gibt.
Ein ganz gutes Beispiel ist das Strategiespiel Risiko. Bei Risiko erhält jeder Spieler zu Beginn einen geheimen Auftrag, den es zu erfüllen gilt, um das Spiel zu gewinnen. Im Spielverlauf kann nun Folgendes beobachtet werden: Auf dem Weg, den Geheimauftrag ohne Rücksicht auf Freundschaft, Diplomatie und die eigene Partnerschaft zu erfüllen, verhilft man regelmäßig seinen Mitstreitern zum Sieg. Ohne das man es will, ohne das man es beabsichtigt, voraussehen oder gar steuern kann. Es gibt selbst in diesem kleinen, einfachen System Seiteneffekte, die sich nicht vorausahnen lassen. Überträgt man dieses Beispiel nun auf ein komplexes System wie eine Organisation, entwickelt sich eine gute Idee davon, wie viel Konfliktpotenzial darin steht, Zielsysteme ohne eine gemeinsame Ausrichtung zu etablieren.

Wie schafft man es nun, alle an einem Strang ziehen zu lassen? Idealerweise mit einem Werkzeug, das die Grundprinzipien der klassischen Zielsysteme aufgreift und an eine moderne agile Arbeitsumgebung anpasst. Und in dem das "alle zusammen an einem Strang ziehen" ein ganz normaler Teil des Findungs- und Festlegungsprozesses ist. So wird die gesamte Organisation, also jeder Mitarbeiter als Mitglied eines Teams, mit einbezogen und ist aufgerufen – sogar aufgefordert! – den Weg zur Zielerreichung, sowie mögliche Seiteneffekte, kritisch zu hinterfragen.

Warum und wozu machen wir was?

Der Aphorismus "Wer nicht mit der Zeit geht, geht mit der Zeit", fasst die Kernaussage sehr gut zusammen. Klassische Zielsysteme wurden in einer Zeit konzipiert und erfunden, in denen es das Internet noch nicht gab. Es war eine Zeit, in der es noch keine Vorstellung von dynamischen Märkten, wie wir sie heute kennen, gab. Für viele Unternehmen gibt es inzwischen gar keine andere Alternative, als sich den Marktbedingungen anzupassen. Gleiches muss auch für das Zielsystem gelten.

Warum Ziele und Zielsysteme im Agilen? - Haltung, Werte, Prinzipien

In Zeiten, in denen Unternehmensprozesse den ständigen Veränderungen nicht mehr standhalten können, braucht es ein anderes Grundverständnis, um die Basis für eine gute und vertrauensvolle Zusammenarbeit zu ermöglichen. Einer der Erfolgsfaktoren muss es sein, die Stärke der eigenen Mitarbeiter besser zu nutzen.

Der Mensch war schon immer sehr gut darin, sich auf Veränderungen einzustellen und sich anzupassen. Unternehmensstrukturen tun sich da bekanntlich deutlich schwerer. Im Manifest der agilen Softwareentwicklung sind die folgenden Werte niedergeschrieben:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Legt man nun diese Werte einmal über ein klassisches Zielsystem und im Vergleich dazu über ein agiles Zielsystem wie OKR, wird man sich unweigerlich die Frage stellen, was passt da besser? Oder anders gefragt: wie erreicht man eine höhere Partizipation aller Mitarbeiter? In dem man ihnen die Ziele und den Weg dorthin vorgibt, oder indem man sie von Beginn an sowohl beim Ziel, wie auch beim Weg dorthin mitarbeiten lässt und einbezieht? Der Weg zu einer partizipativen Unternehmenskultur ist kein leichter, viele Mitarbeiter sind diese Art der Freiheit und die damit verbundene Verantwortung schlicht nicht gewohnt. Langfristig sind Ergebnisse, die in einem solchen Umfeld geschaffen werden, aber deutlich tragfähiger, da das gesamte Unternehmen dahintersteht.

Ohne individuelle Boni oder Constraints mit Mitarbeiterbeurteilung

Kann es ein Zielsystem schaffen, dass alle Mitarbeiter gemeinsam ein Ziel erreichen wollen? Wie soll das gelingen, wenn die altbekannte "Karotte vor der Nase" in Form eines Boni bei Erfüllung der persönlichen Ziele weg fällt? Gleiches gilt für die Mitarbeiterbeurteilung. Am besten, in dem man die Rahmenbedingung schafft und fördert, die Mitarbeiter schon immer motiviert haben, Bestleistungen abzuliefern. Und das ist langfristig – da ist sich die Wissenschaft ja schon länger einig – nicht Geld und subjektive Anerkennung Dritter. Es sind die intrinsischen Motivatoren Autonomie, Meisterschaft und Zweck, die es zu fördern gilt.

Das Manifest der agilen Softwareentwicklung geht in seinen Prinzipien auch auf diese Motivatoren ein. Das agile Zielsystem sollte den Rahmen schaffen, damit jeder Mitarbeiter in die Lage versetzt wird, seine eigenen intrinsischen Motivatoren selbst zu gestalten.

Nicht der Fehler, sondern das Lernenwollen, steht im Mittelpunkt, um bessere Produkte bauen zu können, die beim Nutzer ankommen (und der Nutzer nicht flüchtet).

Je nach Branche und Kultur unterscheidet sich die Fehlerkultur in Organisationen stark voneinander. So gibt es Unternehmen, die in ihren Werten, ihrer Haltung, der Kultur und der Kommunikation stark darauf setzen, Fehler zu vermeiden. Das Resultat einer Fehlerkultur, die auf Fehlervermeidung setzt, ist ein Damoklesschwert namens Angst. Die Mitarbeiter werden Fehler immer als etwas negatives sehen, dass es gilt, unbedingt zu vermeiden. Und das am Ende auch in die Messkriterien (Qualität der Arbeit) einfließt. Welcher Mitarbeiter hat die bessere Arbeit geleistet? Der, der weniger Fehler macht? Ist mit diesem schrägen Grundverständnis ein Lernen aus Fehlern überhaupt möglich? Wohl eher nicht. Denn dazu benötigt der Fehler ein anderes Standing bzw. Image. Also die grundsätzliche Möglichkeit, Fehler zuzulassen, um aus ihnen lernen zu können. Eine Fehlervermeidung ist in komplexen und dynamischen Systemen nicht möglich. Und was viel entscheidender ist, sie ist gar nicht erstrebenswert! Es braucht eine offene Fehlerkultur. Nur so kann aus "Fehler machen, um zu lernen" das gelingen, was über die Jahre auch mit der Fehlervermeidung geklappt hat: dass es als normal wahrgenommen wird. Denn eines sollte man nicht vergessen: Die Evolution eines richtig guten Produktes besteht zum Großteil daraus, Fehler zu begehen und zuzulassen, aus diesen Fehlern für die Zukunft lernen zu können.

Vorstellung diverser Zielsysteme

Wir wissen jetzt, was die Ursprünge von Zielsystemen wie Management by Objectives waren. Warum individuelle Boni nur bedingt funktionieren können, um einem großen Ganzen zu dienen. Doch welche Formen von Zielsystemen gibt es im agilen Umfeld? Im Folgenden schauen wir uns ein paar dieser Systeme näher an.

Vision/Nordstern

Viele Unternehmen haben keine Vision. Oder zumindest keine Vision, die von den Mitarbeitern der Organisation gelebt wird.

Mit einer Vision, auch Nordstern oder True North genannt, verschafft sich die Organisation einen Fixpunkt. Etwas, wonach sie strebt und was sie als Unternehmen auszeichnet. Die Vision sollte prägnant und nicht allzu lange sein. Mitarbeiter und Kunden sollten dadurch wissen oder erahnen können, warum es diese Organisation gibt und was sie dort erwartet. Es wird also eine gemeinsame Ausrichtung erzeugt.

Unsere Vision ist zum Beispiel: Wir führen Unternehmen in die Zukunft – mit modernen Technologien und agiler Organisation.

Weil wir gemäß Conway’s Law an den Zusammenhang zwischen Technologie und agiler Organisation glauben, wollen wir ganzheitlich arbeiten und die Herausforderungen unserer Kunden mit einem ganzheitlichen Blick angehen. Denn das in Kombination mit modernen Technologien führt Unternehmen – unsere Kunden – in die Zukunft. Die Software-Produkte, die wir zusammen mit unseren Kunden in enger, kooperativer Arbeitsweise entwickeln, sollen eben modern sein oder bestehende Software-Systeme modernisiert werden. Ein Erfolgsfaktor ist hierfür, den Blick auch auf die Organisationsstruktur zu werfen und sich zum Beispiel gemeinsam zu fragen, wie Feature-Anforderungen in der Kundenorganisation entstehen und ob diese tatsächlich kundenzentriert ausgerichtet sind.

Soviel zu unserer Unternehmensvision, die noch durch einen längeren Erläuterungstext in unserem Wiki transparent allen Crew-Mitgliedern zur Verfügung steht. Wir haben diese übrigens partizipativ mit der gesamten Mannschaft entwickelt. Wir Geschäftsführer und Eigentümer haben einen Vorschlag erarbeitet und haben uns in einem unternehmensweiten Workshop (kritischen) Rückmeldungen und Fragen gestellt. Über ein moderiertes Format (bei dem wir Eigentümer nur zuhörten und für Rückfragen zur Verfügung standen) sind somit weitere Hinweise zur Schärfung der Vision entstanden. Danach konnten wir die Vision leicht überarbeiten und wie oben stehend als finale Variante vorstellen.

Wir haben beschlossen, im Unternehmen regelmäßig über unsere Vision zu sprechen. Aktuell tun wir dies quartalsweise, in einer Open-Space-Session an unserem Mayday. Das ist nicht nur für neue Mitglieder der Crew ein guter Einstieg, um Fragen und Anmerkungen zu stellen. Sondern wir besprechen auch mit den Teams, inwieweit die Vision tatsächlich gelebt werden kann. Feedback nehmen wir soweit es geht auf und ergänzen es zum Beispiel in unserem Erklärungstext im Wiki.

Außerdem wollen wir die Vision in regelmäßigen größeren Abständen ebenfalls einem Review unterziehen. Wir peilen hier etwa alle 2-3 Jahre an.

Es war für uns ein großes Investment, einen ganzen Tag mit allen zu verbringen. Doch wir glauben daran, dass sich dieses Investment bereits heute schon gelohnt hat: Durch die Möglichkeit, sich einzubringen, Rückmeldung zu geben und kritisch zu hinterfragen, ist der erste Schritt zur Festigung der Vision bei allen getan. Wir raten dir, deine Unternehmensform ebenfalls partizipativ zu entwickeln.

Vorbei sind auch die Zeiten, in denen Visionen für sehr viele Jahre festgeschrieben standen. Genau deswegen möchten wir auch da regelmäßig – getreu Inspect and Adapt – drüber schauen und prüfen, ob die Vision für uns Eigentümer und für die Mannschaft noch stimmig ist.

Ein regelmäßiger Dialog ist das A und O zur Festigung der Vision in der Mannschaft. Es ist keine Pressekonferenz und auch kein PR-Stunt, der hier gelebt wird. Die wichtigsten Notizen aus der Dialog-Session sind für jeden im Wiki nachvollziehbar. Durch die quartalsweisen Treffen bei gleichzeitiger freiwilliger Teilnahme ist gewährleistet, dass dem Thema Vision genügend Raum gegeben wird. Du solltest also darauf achten, regelmäßig mit den Teams über die Vision und die Verankerung im Alltag, mit euren Kunden, zu sprechen.

OKR

OKR in der Tiefe zu erläutern, würde den Rahmen dieses Artikels sprengen. Deswegen legen wir den Fokus auf die Grundlage und die Abgrenzung bzw. Unterscheidung zu klassischen Zielsystemen. Bei OKR – Objectives & Key Results – handelt es sich um ein Management-Framework, das als Werkzeug benutzt werden kann, um strategische Unternehmensziele zu erreichen.

Es dient dazu, sich gegenseitig über strategische Absichten zu informieren, herauszufordern und zu verhandeln. Anders als "Management by Objective" dient es nicht zur Mitarbeiterbeurteilung. Zudem vereint es einen Top-Down-Bottom-Up-Ansatz: Unternehmensziele werden definiert, idealerweise unter Vorschlägen/Feedback von Allen aus dem Unternehmen. Gleichzeitig sind die Teams frei, ihre eigenen Objectives & Key Results zu finden, die auf das oder die Unternehmensziele einzahlen.

Das OKR-Framework ermöglicht zum Einen, sich genügend Spielraum für die Adaption an das eigene Unternehmen zu geben. Auf der anderen Seite gibt es einen ausreichenden Rahmen bzw. Regeln vor, um die enormen Möglichkeiten des Werkzeuges im Arbeitsalltag ausreichend nutzen zu können. Bei den Objectives handelt es sich um Unternehmens- und Team-Ziele. Ein OKR besteht aus einem Objective und mehreren, sehr herausfordernden, quantifizierten Zielen, die dabei helfen, das Objective zu erfüllen. Also bildlich gesprochen darauf einzahlen, dass das große Ziel erfolgreich umgesetzt werden kann.

Die gesamte Organisation arbeitet dabei in Rhythmen. Diese dauern typischerweise 3 oder 4 Monate. Für jede Iteration werden also wieder eigene OKRs gefunden. Diese geben somit den Takt vor, an dem sich die gesamte Organisation ausrichtet.

Eines unserer Unternehmensziele (Company Objective) lautete beispielsweise: "Wir begeistern am Berliner Markt." Wir wollen unserem verhältnismäßig neuen Berliner Standort zu weiterem Aufschwung verhelfen und haben daher ein Company Objective erstellt, das darauf abzielt.

Eines von drei Key Results dieses Company Objective lautete: "3 Projektchancen wurden erzeugt und dokumentiert." Je nach Organisationsstruktur entstehen nun zum Beispiel Bereichs-Objectives, Abteilungs-Objectives oder Team-Objectives, die wiederum mit ihren Objectives und daran gekoppelten Key Results dafür sorgen, dass das Organisations- oder Bereichs-Ziel in messbaren Schritten erreicht werden kann.

Bis zu diesem Punkt unterscheidet sich OKR oberflächlich noch gar nicht so sehr von einem klassischen Zielsystem wie z. B. MbO, oder? Denn auch hier gilt die Formel OKR = Objectives + Key Results die der von MbO gar nicht so unähnlich ist: Gesamtziel des Unternehmens = Summe der Einzelziele.

Naja, nicht ganz. Sehen wir uns die Unterschiede etwas genauer an, um zu erkennen, dass es doch einige sehr gravierende und entscheidende Unterschiede gibt.

Die Objectives werden nicht für ein ganzes Geschäftsjahr fixiert und versucht zu erreichen. Sondern für einen deutlich kürzeren Zeitraum. Die Zeitabschnitte, in denen bei OKR üblicherweise gedacht wird, sind Quartale oder Tertiale. Vorteil: Entpuppt sich ein Objective schlicht als schlechte Wahl oder vielleicht auch als nicht erfüllbar, kann deutlich früher gegengesteuert werden. Zudem ist es so, dass die Zukunft aufgrund steigender Komplexität und hoher (Markt-)Dynamik sowieso nicht in ganz großen Etappen vorhergesagt werden kann. Gleichzeitig bietet der Rahmen von einigen Monaten eine gewisse Stabilität und wirkt somit handlungsleitend für die gesamte Crew.
Objectives werden nicht stur von der Geschäftsführung vorgegeben, und nach unten in die Organisation weitergegeben. Die Erarbeitung, Findung und Einigung der Objectives erfolgt auf jeder Ebene partizipativ mit den Mitarbeitern. Es wird so ein möglichst großes Verständnis und eine hohe Akzeptanz erreicht. Vorteil: Nur wer einbezogen wurde, sieht das Objective auch als "sein" Objective an und wird eigenmotiviert helfen, es zu erreichen. Anders als in der Literatur angegeben, empfehlen wir die Erstellung des Firmen-Objective auch unter Partizipation der Mitarbeiter, z. B. in Form eines teilhabenden Führungskreis.
OKR ist kein Instrument zur Mitarbeiterbeurteilung. Im OKR-Framework gibt es keinerlei Erwähnung darüber, eine Bewertung der Arbeit eines Mitarbeiters in Kombination mit der Mitarbeit an den Objectives vorzunehmen. Objectives werden typischerweise auf Team-Ebene definiert. Es spricht nichts dagegen, auch persönliche Objectives auf Mitarbeiter-Ebene zu definieren – dies macht jedoch ein Mitarbeiter für sich selbst. Vorteil: Mitarbeiter, die wissen, dass es um ihren Einsatz und ihre Ideen zur Zielerreichung geht, und nicht darum, andauernd bewertet zu werden, werden für die Erfüllung des Objectives arbeiten. Und dies nicht, um für sich einen eigenen Vorteil (Bonus) zu erzielen, sondern weil sie hinter dem gemeinsamen Ziel stehen.
Team Objectives sollten – müssen aber nicht – auf Company Objectives einzahlen. Mitarbeiter haben so einen kreativen Freiraum, sich auch Gedanken für Verbesserungen abseits der Company Objectives zu machen. Jedoch sollte ein Team wenigstens ein Objective finden, das auf ein Company Objective einzahlt. Vorteil: Für diesen Innovationsfreiraum bleibt sonst neben dem Tagesgeschäft keine Zeit.
Es entsteht Raum, um gemeinsam zu lernen. Die Key Results der Objectives sollten als recht ambitionierte Ziele, sogenannte Moonshots definiert werden. Bei diesen geht es gar nicht um eine 100-prozentige Erfüllung der Zielvorgaben, sondern vielmehr darum, gemeinsam an diesem ambitionierten Ziel zu arbeiten und vor allem zu lernen. Vorteil: Die Grundeinstellung sollte sich von dem Zwang lösen, eine 100-prozentige Erfüllung als wünschenswertes Ziel zu betrachten. Und andere, relevantere Dinge, wie gemeinsames Lernen in den Fokus zu rücken.
Es erfolgt ein Austausch zwischen den Mitarbeitern, um Abhängigkeiten zu erkennen und aufzulösen. Dieser Aspekt der Ausrichtung fehlt bei klassischen Zielsystemen komplett, und sorgt nicht selten dafür, dass Mitarbeiter nicht zusammen an einem Ziel, sondern einfach oft gegeneinander arbeiten. Dieser Austausch erfolgt über einen Querschnitt der Organisation (via Rituale z. B. AllHands-Meeting) und ermöglicht es, dass Mitarbeiter aus ganz unterschiedlichen Bereichen miteinander reden, um sichergehen zu können, dass es keine Blockaden, Seiteneffekte oder seitliche Abhängigkeiten bei den Key Results gibt. Ohne Austausch und Transparenz kann keine kollektive Ausrichtung erfolgen. Vorteil: Seitliche Abhängigkeiten, die sonst ignoriert oder einfach in Kauf genommen werden, werden adressiert und eigenverantwortlich durch die Mitarbeiter aufgelöst.
Ein weiterer Aspekt ist das Herausfordern oder Challengen der Teams untereinander in Bezug auf ihre gewählten OKRs. Es entsteht dabei eine positive Challenge-Zone. Also ein Umfeld, in dem ohne Leistungsdruck jedes Team versucht, bestmöglich auf das Objective einzuzahlen und sich durchaus kritisch, aber sportlich, gegenseitig herausfordert, um herauszufinden, an welchen Stellen sie sich gegenseitig unterstützen können. Oder festzustellen, dass die Objectives zweier Teams widersprüchlich in Bezug auf das Company Objective sind – und durch den gemeinsam eine Änderung in den Objectives beider Teams entsteht, zum Wohle des Gesamtziels. Vorteil: Das kann, wenn man den Grundgedanken hinter den Moonshots verstanden hat, einen Motivationsschub für die Mitarbeiter erzeugen.
Last but noch least fördert OKR den Austausch zwischen Mitarbeitern, ganz gleich, ob es die Firmenorganisation nun unterstützt oder nicht. Im Vergleich zu MbO reicht es bei OKR nicht aus, einmal das Wunschziel zu verabschieden, und dann jeden Mitarbeiter alleine vor sich hin werkeln zu lassen. Durch vollständige Transparenz aller OKRs zum Beispiel via Firmen-Wiki, durch regelmäßigen Dialog und Status-Updates in Bezug auf das Erreichen der Key Results wird so ein Gesamt-Austausch in der Organisation gefördert. Idealerweise weiß jeder zu jeder Zeit über den aktuellen Status der eigenen Team-Ziele sowie der Ziele der anderen Teams Bescheid, oder kann sich darüber schnell und einfach informieren. Vorteil: Das OKR-Framework enthält Rituale, die die Zusammenarbeit fordern und fördern. Dazu gleich noch mehr.

Was braucht es, um mit einem guten Rüstzeug für OKR zu starten?

Um den Start, die Grundhaltung und den langfristigen Erfolg von OKR zu unterstützen, ist eine Unternehmens-Vision recht zweckdienlich. Diese Unternehmens-Vision muss zum Start von OKR nicht zwingend vorhanden sein, sollte jedoch spätestens ein oder zwei Zyklen nach dem Start zur Verfügung stehen. Sie hilft allen Mitarbeitern das große "Why" zu verstehen und zu verinnerlichen. Sie ist das Fundament für ein kollektives Alignment, also eine Ausrichtung an einem gemeinsamen Firmenziel.

Darüber hinaus gibt das OKR-Framework ein gutes Set an Ritualen vor, die helfen, OKR in die tägliche Arbeit zu integrieren. Die wichtigsten werden an dieser Stelle kurz erläutert.

Company-OKRs erarbeiten

Weiter oben ist beschrieben, dass einer der Erfolgsfaktoren darin besteht, die Company-OKRs nicht durch die Geschäftsführung vorzugeben und nach unten in die Organisation zu geben, sondern diese Company-OKRs gemeinsam mit den Mitarbeitern zu erarbeiten. Diese Erarbeitung ist nicht einfach, und der Zeitaufwand bei den ersten Iterationen sollte nicht unterschätzt werden. Denn diese Punkte gilt es in einer großen Runde zu bewältigen:

Ideen sammeln für ein gemeinsames Company Objective.
Aus diesen Ideen einen Favoriten wählen.
Die Formulierung so zu wählen, dass alle in der Runde hinter diesem Objective stehen. Das Alignment und "Wir-Gefühl" sollte in einem guten Objective mitschwingen.
Steht das Objective, gilt es passende Key Results zu erarbeiten.
Hier gilt die Devise: Weniger ist mehr. Soll heißen, zu Beginn ist allen Mitarbeitern – also der gesamten Organisation – mit wenigen, aber dafür gut ausformulierten, Key Results besser geholfen.
Die Key Results müssen so formuliert sein, dass deren Erreichung klar dazu beiträgt, das Company Objective zu erreichen.
Die Key Results müssen so definiert werden, dass die Menge der Arbeit benannt wird, und spürbar (messbar) dazu beiträgt, das Company Objective zu erreichen. Die Herausforderung: Die Menge muss fordernd bzw. ambitioniert sein, darf aber gleichzeitig nicht überfordern. Es darf nie der Eindruck entstehen: "...das schaffen wir doch nie!" oder: "Unmöglich, das lassen wir lieber gleich sein!"

Tipp von unserer Seite: Es benötigt einen guten Moderator, der sowohl die Agenda als auch die Zeit gut im Auge behält, und sich auch traut, mutig nicht zielführende Diskussionen abzubrechen.

AllHands-Treffen

Das AllHands-Treffen ist, wie der Name schon sagt, ein Treffen mit allen Mitarbeitern der Organisation. In diesem AllHands, das kompakt gestaltet ist, geht es um das gegenseitige Informieren der jeweiligen Team-Ziele. Die Teams stellen ihre Objectives und Key Results vor und argumentieren, warum sie damit auf das Firmen-Objective einzahlen.

In einem nächsten Abschnitt des AllHands-Treffens sammeln die Teams nun von anderen Teams Feedback ein. Dazu findet auch das sogenannte "Challenging" statt: Wenn zwei Teams entdecken, dass sie eine gegenseitige Abhängigkeit haben (zum Beispiel aufgrund einer Lieferleistung), dann tauschen sie sich dazu aus und überlegen, wie sie zusammen am besten auf das große Firmen-Ziel einzahlen. Aber auch konstruktive Kritik ist in diesem Challenging erlaubt: Gibt es zum Beispiel eine Rückmeldung, dass das Team-Objective zwar gut ist, die Key Results jedoch noch etwas herausfordernder gestaltet werden sollen? Zahlt überhaupt das Team-Objective auf das Company-Objective ein?

In diesem herrlichen selbstorganisierten "Durcheinander" findet also ein Ausgleichsprozess zwischen den Team-Zielen statt. Die Flotte formiert sich also eigenständig in Ausrichtung auf das Firmen-Ziel. Das macht das AllHands so wertvoll!

Nach Abschluss des AllHands sind idealerweise alle gut ausgerichtet und haben wertvolles Feedback bekommen. Gegenseitige Lieferleistungen zwischen Teams wurden identifiziert. Abhängigkeiten wurden soweit möglich aufgelöst. Key Results verbessert und Team-Objectives angepasst. Die Flotte kann nun in See stechen, um auf das Firmenziel hinzuarbeiten.

Team-Weeklies (Monday Commitments + Friday Wins)

Die Team-Weeklies trennen sich wiederum in zwei Termine auf. Während das Team-Objective das Ziel innerhalb der Zeitspanne (zum Beispiel Quartal) aufzeigt, überlegt sich das Team wöchentlich, welche Aufgaben es erledigen möchte, um auf die Key Results des Team-Objective einzuzahlen.

Die Festlegung der Wochenaufgaben finden in den sogenannten Monday Commitments statt. Es gibt keine feste Struktur für dieses Format, in der Literatur finden sich diverse Empfehlungen für den Aufbau. Häufig geht es darum, herauszufinden, auf welche Aufgaben sich das Team für diese Woche fokussieren und commiten sollte und ob andere Metriken, sogenannte Firmen-Health-Metriken, dadurch nicht gefährdet werden. Hier sollte jede Organisation/ jeder Bereich herausfinden, was am besten als Format passt.

Die Friday Wins ist ein kurzes "Feier-Ritual", in dem die erfolgreich abgeschlossenen Aufgaben aus den Monday Commitments gefeiert werden. Die Ausgestaltung des Rituals kann teamübergreifend erfolgen, muss jedoch nicht. Wie immer kommt es auf den Kontext und vor allem auf die Kultur des jeweiligen Unternehmens an.

Regelmäßig wird dabei auch die Erfüllung der Key Results geprüft. Das kann mit Tools geschehen, für die es mittlerweile eine große Anzahl auf dem Markt gibt. Oder old school in einem Spreadsheet oder einem Wiki.

Wenn ein Key Result also heißt "Wir veröffentlichen 10 Blog-Beiträge", der aktuelle Stand bei 4 ist und diese Woche ein weiterer veröffentlicht wurde, dann setzen wir das Key Result auf 5.

Gleichzeitig findet ein "Grading" des Key Results statt. Das ist vergleichbar mit einer Confidence, also der Zuversicht des Teams, die Erfüllung des Key Results bis zum Ende der OKR-Iteration (also z. B. Quartal oder Terzial) zu erreichen. Das Grading wird typischerweise in Prozent angegeben. Sind wir sehr zuversichtlich? Dann 0,7 oder 0,8 von 1. Über das Grading bestimmt das Team für sich den Kompass, ob eine gute Erreichung der Key Results möglich ist. Wenn nicht, so sollte das Team nach Inspect & Adapt prüfen, was es verändern kann. Ein idealer Ausgangspunkt also für die Diskussion auf dem nächsten Monday Commitment.

Tipp: Es ist durchaus in Ordnung, auf der Reise zur Erfüllung des Team-Objectives die Key Results zu adaptieren, neue hinzuzufügen oder ein Key Result, das nach Meinung des Teams nicht mehr funktioniert, auch rauszunehmen. Wichtig hierbei ist, dass nicht zu viele Schwankungen durch regelmäßiges Verändern oder Wegnehmen von Key Results erzeugt werden.

Retrospektive am Ende eines Zyklus

Der OKR-Zyklus neigt sich dem Ende entgegen. Zeit, sich auch Gedanken zum OKR-Prozess zu machen. Auch wenn es in der Literatur nicht vorgeschrieben ist, so gehört es doch zum guten Ton in der agilen Welt, regelmäßige Feedback- und Lernschleifen in Systeme einzubauen.

Wir empfehlen:

Eine kleine Retrospektive zum OKR-Prozess an sich, regelmäßig gegen Ende eines Zyklus und vor Start des neuen Zyklus: Passen alle Rituale? Müssen wir etwas anpassen? Wie gut ist die Beteiligung auf den AllHands-Treffen? Hier empfiehlt es sich, eine kleine Gruppe an "OKR Mastern" (Rolle) zu definieren, die sich um den Prozess kümmert und in Kooperation mit der Unternehmensleitung und den Mitarbeitern Adaptionen am OKR-Vorgehen durchführen.
OKR-Team-Retrospektive: Wie lief es für uns als Team? Was war gut, was können wir beim nächsten mal besser machen? Waren unsere Key Results zu ambitioniert? Auch hier sollte das Team eine Lern- und Adaptionsschleife fahren, um sich beim Finden der nächsten Team-OKRs verbessern zu können

Wichtig dabei ist: Macht es so, wie es am besten für euch, in eurem Kontext, in eurer Organisation funktioniert. Weil es ein paar Iterationen dauert, bis es sich gut im Unternehmen eingeschleift hat, bedeutet das auch: Es dauert eine Weile, schließlich denkt ihr mindestens in Quartalen. Rechnet also mindestens mit 9-12 Monaten Dauer, bis OKR gut in eurem Unternehmen "angekommen" ist.

Product-Vision

Wenn du ein Produkt entwickelst, so ist es ratsam, eine sogenannte Product-Vision zu haben. Damit erreichst du

eine Ausrichtung des Produktentwicklungsteams auf den Sinn & Zweck des Produkts,
eine Fokussierung auf bestimmte Kunden(gruppen),
eine Fokussierung auf den Hauptzweck, weswegen deine Kunden das Produkt benutzen wollen und
eine Herausarbeitung der wichtigsten Unterscheidungsmerkmale zwischen deinem Produkt und den wichtigsten Konkurrenzprodukten.

Im agilen Umfeld wollen wir wie gehabt erreichen, kurz und bündig zu formulieren. Außerdem soll die Product-Vision ebenfalls einem regelmäßigen Review unterzogen und ggf. angepasst werden. Die Product-Vision soll Klarheit schaffen und im besten Fall inspirierend und/oder anziehend wirken. Sie gibt einen Ordnungsrahmen vor, der sich dann zum Beispiel auf entsprechende Epics und Features für das Product Backlog auswirkt.

Eine Product-Vision kannst du nicht nur für ein digitales Produkt verwenden, sondern zum Beispiel auch für eine Veranstaltung. Hier als Beispiel die Product-Vision unserer Unkonferenz für Product Owner:

Für Product Owner, Projektmanager, Produktmanager und Requirements Engineers, die sich im Agilen Kontext weiterbilden und mit Peers austauschen wollen, ist das Product Owner Camp die zentrale Community-Veranstaltung

Anders als existierende Camps für diese Zielgruppe bietet das Product Owner Camp

Austausch statt Werbung dank Open Space Format,
mehr Teilnehmer aus "Endanwender-Unternehmen" als Berater und Dienstleister,
echte Beispiele und Herausforderungen aus der Praxis,
konkrete Praxis-Workshops im Vorfeld des Camps,
(Foto-)Dokumentation der Session-Ergebnisse im Nachgang verfügbar und
Abendveranstaltung zur Vertiefung der geschlossenen Kontakte.

Wie man sieht, findet sich in dieser kurzen Beschreibung alles, was die Veranstaltung ausmacht: Die Zielgruppe, an die wir uns richten; die Ziele, die die Zielgruppe verfolgt; was unser Produkt ist und welche "Features" wir gegenüber dem Mitbewerber – also andere Veranstaltungen – bieten.

Es ist hilfreich, wenn die Beschreibung pragmatisch-kurz ist. Wenn ein längerer Text heraus kommt, dann ist in der Regel eines sicher: Niemand liest sich das durch. Achte daher auf eine passende Kürze. Die Product-Vision ist dazu da, dass alle an der Produktentwicklung Beteiligten zielgerichtet wissen, worum es bei dem Produkt geht.

Auch hier ist wichtig, dass die Product-Vision partizipativ entwickelt wurde. Bindet euer Entwicklungsteam ein, lasst es mit Ideen teilhaben und an einigen Entscheidungen mitwirken. So entsteht eine viel größere Zugkraft, als wenn die Entwickler rein nur in die Rolle des "Umsetzers" geraten – denn dann wird auch in der späteren Entwicklung das Engagement leiden.

Zudem sollte die Product-Vision in regelmäßigen Abständen einem Review unterzogen werden. Vielleicht hat sich eure Zielgruppe verändert. Oder ihr habt festgestellt, dass eure Nutzer das Produkt zur Lösung ganz anderer Probleme verwenden. Möglicherweise habt ihr im Laufe der Zeit auch einige weitere Killerfeatures entwickelt, von denen sich herausstellt, dass sie ideale Differentiatioren zu anderen Konkurrenzprodukten sind – ihr das aber bisher noch nicht auf dem Schirm hattet.

Sprint-Ziel

Das Wort Ziel steckt schon drin. Trotzdem fällt es manchen Teams noch schwer, das Sprint-Ziel als das anzuerkennen, was es ist: Ein Zielsystem im agilen und zwar limitiert bzw. fokussiert auf einen Scrum-Sprint. Das Sprint-Ziel kann durchaus als eine Art Team-Vision für einen Sprint gesehen werden, hinter dem das ganze Team steht. Wie kann ein Team auf einen erfolgreichen Sprint hinarbeiten, wenn im Vorfeld nicht geklärt wurde, was genau einen Sprint erfolgreich macht? Allen im Team muss klar sein, dass sie nur gemeinsam das Sprint-Ziel erreichen können, und die Abarbeitung des Backlogs nach Priorität alleine nicht ausreicht. Denn erst, wenn im Team eine Einigkeit über das "Was" (Sprint-Ziel) besteht, kann sich das Team auf das "Wie" konzentrieren.

Retrospektive

Wenn wir bei den Scrum-Ritualen bleiben, muss auch die Retrospektive als agiles Zielsystem angesehen werden. Nimmt man das folgende Zitat aus dem deutschen Scrum-Guide steht dort: Die Sprint Retrospektive wird durchgeführt, um

zu überprüfen wie der vergangene Sprint in Bezug auf die beteiligten Personen, Beziehungen, Prozesse und Werkzeuge verlief;
die wichtigsten gut gelaufenen Elemente und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen; und
einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Scrum-Teams zu erstellen.

Somit ist die Retrospektive ein Zielsystem mit Rückspiegel, das nicht nur den Sprint, sondern die gesamte Arbeit des Teams und der Beteiligten in den Fokus rückt, und hilft die kommenden Sprints besser zu planen.

Daily Scrum

Natürlich darf hier auch das Daily Scrum nicht fehlen. Das Daily ist ebenfalls als agiles Zielsystem zu sehen, das als Zeithorizont den aktuellen Tag hat. Das Ziel ist, die Arbeitsergebnisse seit dem letzten Daily auszutauschen, und das Team so in kleinen, regelmäßigen Schritten auf Kurs zu halten/bringen. Wichtig ist, die Timebox für ein Daily im Auge zu halten (Dauer max. 15 Min.) und das Ritual z. B. mit Hilfe dieser Fragen zu strukturieren:

Was habe ich seit dem letzten Daily erreicht?
Was nehme ich mir vor, bis zum nächsten Daily zu erreichen?
Habe ich Probleme, brauche ich Unterstützung durch das Team?

User Story

Das kleinste Zielsystem im agilen Kontext bildet die User Story. Die User Story ist eine Anforderung, die aus User-/Kundensicht formuliert ist. Bei User Story hat sich dieses beispielhafte Format bewährt: "Als <Rolle des Users/Kunden> möchte ich <Ziel/Wunsch>, um <Nutzen/Mehrwert> zu erreichen."

Dieses Format hat den großen Vorteil, dass der User/Kunde und seine Bedürfnisse zentral in den Mittelpunkt gestellt werden. Entwickler sind so deutlich besser in der Lage, sich in die Person hineinzuversetzen, die später das Produkt verwenden wird. Ron Jeffries hat mit den sogenannten drei C (Card, Conversation, Confirmation) eine sehr gute Eselsbrücke geschaffen, worauf es beim Erstellen von User Stories ankommt. Sein Artikel gilt heute zurecht als Referenz bzw. essentieller Bestandteil des XP aus dem das Scrum-Framework entstanden ist [2]. Die Essenz des Artikels ist im folgenden erläutert.

Card: Die Grundidee ist, die User Story so kurz zu halten, so dass sie auf eine Karte passt. Dabei geht es nicht darum, möglichst viele Details der Anforderung zu beschreiben, sondern sich auf das Bedürfnis des Users zu beschränken. Dem Team muss das WAS (Bedürfnis) klar sein, das WIE (Technik) ist an dieser Stelle nicht relevant.

Conversation: Die Anforderung selbst sollte dabei vom Kunden (User) an das Team (Programmierer) durch Konversation übergeben werden. Dieser gegenseitige Austausch von Gedanken, Möglichkeiten und Gefühlen hilft beiden Seiten, die Bedürfnisse besser zu verstehen. Die Konversation sollte zum Großteil verbal erfolgen, sich wiederholen und wird am besten durch konkrete Beispiele und bei Bedarf erklärende Dokumente unterstützt. Anhand dieser Konversation entsteht in den Köpfen aller Beteiligten idealerweise ein gemeinsames Bild darüber, was der User benötigt, um einen Nutzen aus einer Anforderung zu ziehen.

Confirmation: Am Ende wird noch die Möglichkeit benötigt, die Realisierung einer User Story in gewünschter Form prüfen zu können. Es müssen also verbindliche Akzeptanzkriterien definiert werden, gegen die man prüfen kann, und dem Kunden und dem Team die Bestätigung zu geben, dass die Anforderungen gut umgesetzt wurden. Wichtig dabei ist, die Verbindlichkeit nicht im Sinne eines fixen Vertrags zu sehen. Sondern Verbindlichkeit im Sinne einer gemeinsamen Bestätigung, dass das was als User Story benötigt wurde, auch tatsächlich in Form eines aus Nutzersicht funktionierenden Features realisiert wurde.

Spike (eXtreme Programming)

Ein Spike ist eine Art zeitlich beschränkte Lerneinheit. Ein Software-Team verfolgt dabei das Ziel, Wissen zu generieren. Dies kann nützlich sein, wenn zum Beispiel bestimmtes Wissen für eine zukünftige User Story noch nicht ausreichend zur Verfügung steht und dies explorativ erzeugt werden soll. Beispielsweise werden durch einen Spike kleine Prototypen gebaut, um das notwendige Wissen zu bekommen. Ein Spike könnte zum Beispiel sein: "Was hat sich von V1 auf V2 der eingesetzten Frontend-Bibliothek verändert, das wir bei der Migration beachten müssen?".

Der Spike wird ganz normal im Product Backlog als Product Backlog Item definiert und in Sprints eingeplant. Anders als bei User Stories wird der Spike typischerweise in Zeit geschätzt und angegeben, ob das gesamte Team oder Teile des Teams daran arbeiten werden. Über das Refinement-Ritual wird der Spike beschrieben – idealerweise vom Team selbst.

Der Spike enthält somit ein klares Ziel, das erreicht werden soll. Es hilft dem Team, sich dadurch zu fokussieren und neues Wissen zu generieren.

Ausblick: Welche agilen Zielsysteme gibt es noch?

Es gibt noch eine ganze Reihe weiterer Zielsysteme, die im agilen Kontext verwendet und teilweise auch unter- und miteinander kombiniert werden können. Diese sind zum Beispiel die Kanban Flight Levels, das 3-Horizon-Modell oder Lean Canvas. Eines eint all diese Zielsysteme: Die Partizipation, also Mitarbeit, eines großen Teils oder des gesamten Unternehmens, sowie der iterative Lern-Charakter, mit dem alle diese Systeme in der Praxis durch Retrospektiven/Reviews arbeiten.

Fazit

Das Spiel hat sich geändert. Ist es dann nicht auch langsam an der Zeit, die Spielregeln anzupassen? Eine Marktdynamik, die damals noch niemand vorausahnen konnte, ist inzwischen Alltag. Mitarbeiter sind schon lange keine reinen Befehlsempfänger, die nicht einbezogen werden dürfen. Im Gegenteil: Menschen müssen viel stärker ins Zentrum gerückt werden. Mit Menschen sind alle Beteiligten einer Organisation bzw. eines Systems gemeint: Die eigenen Mitarbeiter, Teammitglieder, Kunden, User, Stakeholder, Abteilungsleiter, Manager, …

Nur wenn man die Spielregeln dahingehend ändern wird, dass alle, die es braucht, um ein Ziel zu erreichen, an einem Strang ziehen, wird man langfristig erfolgreich sein können. Um bei der Metapher mit dem Spiel zu bleiben: Nur wer versteht, dass das geänderte Spiel auch zwingend angepasste Spielregeln braucht, wird in Zukunft eine reale Chance haben, weiterhin mitzuspielen und auch gewinnen zu können. Agile Zielsysteme, insbesondere OKR, können ein langer, stabiler Hebel sein, um allen Mitarbeiter die unternehmensweiten Ziele zu vermitteln und sie zum Mitspielen einzuladen. Wenn man es gut hinbekommt, werden die Mitarbeiter, die sich einbringen, versuchen, intrinsisch einen erheblichen Beitrag zu leisten und ihr Bestes geben. Nicht weil sie es müssen, sondern weil sie es möchten. Auf lange Sicht kann das ein entscheidender Faktor für eine Organisation sein. OKR hat das Potenzial, die Stärken der Mitarbeiter zu fördern, und gleichzeitig genug Flexibilität und Spielraum, um es an die unterschiedlichsten Organisationen anpassen zu können.

OKR vereint Akzeptanz und Ausrichtung mit dem agilen Inspect-&-Adapt-Grundsatz und ist eine zukunftsfähige Antwort auf klassische Zielsysteme, die den heutigen Ansprüchen häufig nicht mehr genügen.

Quellen