OKR und Scrum – 13 Tipps um Scrum in OKR zu implementieren

Zunächst ein paar grundlegende Gemeinsamkeiten zwischen Scrum und OKR:

• Zyklisches Arbeiten: Beide Rahmenwerke setzen auf Arbeiten in fest definierten Zyklen, operationalisiert über feststehende Events (Planning, Review, Retro).
• Prozesstreue: OKR und Scrum leben von einer hohen Prozesstreue und damit einhergehender Disziplin.
• Transparenz: Beide Vorgehensmodelle setzen auf eine hohe Transparenz.
• “Done Work”: Scrum und OKR setzen auf konkrete Ergebnisse zum Ende eines Zyklus.
• Kundenfokus: Scrum und OKR haben einen hohen Kundenfokus, die Realisierung von Customer Value hat eine hohe Bedeutung.
• Überprüfung und Anpassung: Scrum und OKR basieren auf empirischer Prozesskontrolle.

Das sind erstmal gute Nachrichten, weil sich Scrum und OKR von den grundlegenden Prinzipien und Denkweisen sehr ähneln. Und gleichzeitig gibt es einige wesentliche Unterschiede, die es erforderlich machen, die beiden Rahmenwerke gut miteinander zu verzahnen. 

Grundsätzlich ist das OKR Rahmenwerk nicht so eng und klar spezifiziert wie Scrum. Das heißt, Du hast bei OKR einige Stellschrauben, um Scrum optimal in deine Arbeit mit OKR zu integrieren.

Zuerst einmal zeige ich dir, wie Du beide Rahmenwerke so aufstellst, dass sie überhaupt gut zueinander passen. Weiter unten gehe ich dann auf das alltägliche Arbeiten ein und wie Du einzelne Events und Aktivitäten sinnvoll synchronisiert. 

1. Sprint in den OKR Zyklen integrieren
2. OKR Zyklen deinem Umfeld anpassen
3. OKR und Scrum Architektur - One Team Scrum, skaliertes Scrum
4. Product Goals sind OKR
5. Scrum Master sind OKR Coaches oder besser nicht?
6. OKR managt Strategie, Scrum die operative Umsetzung

Um Scrum und OKR zu verbinden, solltest Du zuerst die Länge deiner Sprints an deinen OKR Prozess anpassen. Das heißt, startet ein neuer OKR Zyklus, dann startet auch ein neuer Sprint. Genauso ist der letzte Sprint mit dem Ende des OKR Intervalls synchronisiert. Somit ist ein OKR Prozess also eine Abfolge von Scrum Sprints.

Beispiel: Dein OKR Zyklus dauert 3 Monate bzw. 12 Wochen, dein Scrum Sprint geht über 2 Wochen. Somit ergeben sechs Scrum Sprints ein OKR Intervall. Oder anders herum gesagt: Du hast sechs Sprints Zeit, deine OKR zu erreichen.

Ein weiterer wichtiger Punkt um Scrum in OKR zu implementieren ist, dass Du die Länge des OKR Intervalls deinem Umfeld anpasst. Wenn dir drei Monate für die Arbeit mit OKR zu lang sind, dann gehst Du auf zwei runter. Wenn dagegen drei Monate zu hektisch sind, dann definierst Du OKR in 4 Monaten. Dabei solltest Du bei der Wahl deines OKR Zyklus folgendes berücksichtigen:

1. Jedes OKR Intervall bringt Overhead mit sich, wenn die Zyklen zu kurz werden, könnte das unproduktiv sein.

2. Ein OKR Intervall sollte lange genug sein, um echte Outcomes zu erreichen. Das heißt, messbaren Customer- und Business-Value. Je kürzer die Zyklen, desto eher die Gefahr, in Outputs und Aktivitäten statt in Outcomes zu denken.

3. Die Länge eines Zyklus ist Ausdruck deiner strategischen Unsicherheit und keine strenge Vorgabe.

Probiere mit deinen Teams einfach aus, welches zeitliche Intervall für die Arbeit mit OKR am besten zu deinem Vorhaben passt.

Bei der Implementierung von Scrum und OKR kommst Du irgendwann an den Punkt, deine ideale OKR Architektur auszuarbeiten. Dabei spielen vor allem zwei Punkte eine wichtige Rolle:

1. Aufbau deines Scrums: Arbeitest Du mit nur einem Scrum Team oder ist deine Organisation in einem Scrum of Scrums (also z.B. LeSS, Helix, Scrum of Scrums) aufgesetzt. 
2. OKR Architektur: Der idealtypische Aufbau einer OKR Architektur hat zwei Ebenen. Eine mittelfristige Unternehmens- oder Produktebene mit OKR über 12-36 Monate und eine kurzfristige Team-Ebene mit OKR über 2-4 Monate.

Vor allem der zweite Punkt sorgt regelmäßig für Verwirrung. Schließlich kennt das Scrum Framework noch Product Goals. Damit das nicht zu kompliziert wird würde ich es einfach halten, gerade wenn Du anfängt Scrum in OKR zu implementieren: 

1. Ein Set von OKR für dein gesamtes Scrum für die nächsten drei Monate. Sofern dein gesamtes Unternehmen mit OKR arbeitet, sind diese natürlich mit den Unternehmens OKR verknüpft. 
2. Einzelne Scrum Teams haben keine OKR. Sondern jedes Scrum Team orientiert sich an den OKR ad 1. Dabei hat idealerweise jedes Arbeitspaket im Rahmen eines Sprint einen klaren Bezug zu einem OKR. Was das heißt und wie das geht, zeige ich dir weiter unten. 

Das ist in meinen Augen eine einfache und wirkungsvolle Implementierung von Scrum in OKR, für die es keine OKR Beratung braucht. Eine besondere Rolle für die Implementierung von Scrum in OKR spielen zudem deine Product Goals, auf die ich im folgenden Absatz eingehe.

Um Scrum in OKR einzubinden, solltest Du deine Product Goals in Form von OKRs definieren. Mach dich dabei jedoch nicht zum Sklaven eines vorab definierten OKR Zyklus. Wenn Du für das Erreichen eines Product Goals zwei Zyklen benötigst, dann formuliere lieber gute OKR für das Ende des zweiten OKR Intervalls und verzichte auf einen OKR dazwischen. Es ist besser, zielführende OKR zu formulieren, statt dich zum Sklaven eines 3-Monats-Zyklus zu machen und “Zwischen” OKR zu formulieren, die am Ende nur Aktivitäten oder Outputs dokumentieren. 

Beispiel: Du willst ein neues Epic bzw. ein sehr umfangreiches Leistungsmerkmal realisieren, dessen Implementierung ein wichtiges Product Goal ist. Gleichzeitig weißt Du, dass für die Realisierung ein Zyklus von drei Monaten zu kurz ist, um das Feature durch mehrere Iterationsschleifen hindurch zu optimieren und echte Outcomes zu erzielen. Nun gäbe es zwei Wege darüber nachzudenken:

• Gut: Du formulierst ein Product Goal über zwei OKR Zyklen und verzichtest auf einen Zwischen OKR. Das heißt, dieses Ziel willst Du nach sechs Monaten innerhalb von 13 Sprints erreichen. 

• Blöd: Du machst dich zum Sklaven des OKR Zyklus und definierst auch für das Ende des ersten Zyklus ein OKR, obwohl Du bis zu diesem Zeitpunkt noch gar keine echten Outcomes erreicht hast.

Eine alternative Strategie ist natürlich, das Epic so zu zerlegen, dass Du bereits gute vorzeigbare Ergebnisse z.B. mit einer Testgruppe zum Ende des ersten OKR Zyklus erreicht hast. 

Es scheint augenscheinlich, dass Du deine Scrum Master auch zum OKR Coach ernennst. Der Vorteil ist, dass deine Scrum Master in der Befähigung von Teams Erfahrung haben und bereits mit den Teams arbeiten. Die große Gefahr ist allerdings, dass ein Scrum Master nicht ausreichend Erfahrung und unternehmerische Perspektive einbringt. Schließlich ist OKR nicht einfach nur ein Prozess. Sondern OKR ist ein Rahmenwerk, um Unternehmens- und Produktstrategie umzusetzen und an entsprechenden Zielen zu arbeiten. Hier ein paar Tipps, wie Du deine Scrum Master effektiv in die Arbeit mit OKR einbeziehst. 

• Das erstmalige Aufsetzen des OKR Rahmenwerks solltest Du im Idealfall mit einer OKR Beratung machen,
• Die Scrum Master benötigen etwas Sparring und eine Ausbildung als OKR Coach, um Teams wirkungsvoll in der Arbeit mit OKR zu begleiten. Diese Ausbildung sollte die Unterschiede zwischen Scrum und OKR, die Wichtigkeit einer Outcome-orientierten OKR Formulierung, guter Objectives und Key Results aufzeigen. 

Nach 1-2 Tagen Ausbildung und ein wenig “training on the job” sind deine Scrum Master dann auch wirkungsvolle OKR Coaches.

Um Scrum in OKR zu integrieren, ist es essentiell zu verstehen, welchen Zweck die beiden Rahmenwerke haben. OKR ist ein Rahmenwerk, um Strategie umzusetzen. Dagegen managst Du mit Scrum operative Arbeit bzw. konkrete Maßnahmen. Dazu mal ein kurzer Dreiklang von Richard Rumelt, was gute Strategie eigentlich ist. Daraus ergibt sich dann auch, wie Scrum und OKR zusammenspielen.

1. Diagnose: Eine gute Strategie startet mit einer guten Analyse und kritischen Herausforderungen. Richard Rumelt nennt sein Vorgehen auch “challenge based strategy”, für mich ist diese Diagnose im Kern gutes Design Thinking und System Thinking.

2. Leitlinien: “Guiding principles” geben deiner Strategie einen Rahmen, darin können sich z.B. Leitlinien für deine technische Architektur finden, wie Du arbeiten willst (z.B. inhouse Entwicklung vor Outsourcing) oder Leitsätze, dass Du Customer- höher als Business Value gewichtest. Generell kannst Du dir Leitlinien wie z.B. das agile Manifest vorstellen. Das heißt, hier werden allgemeine Grundsätze dokumentiert, die sich jedoch auf deine konkreten Herausforderungen beziehen. 

3. Maßnahmen: Konkrete Maßnahmen und Aktionen, wie Du deine aus der Diagnose definierten Probleme lösen willst.

Basierend auf dieser Vorarbeit kannst Du nun OKR formulieren, die ausgehend von den vor dir liegenden Herausforderungen das gewünschte Ziel dokumentieren. Dagegen finden sich deine Maßnahmen im Backlog wieder, werden priorisiert und in Sprints umgesetzt. Mehr Tipps und Hinweise, wie Du eine gute Strategie für dein Produkt erarbeitest, findest Du in unserem Beitrag zur Gestaltung von Strategieworkshops.

Nachdem Du das OKR Rahmenwerk aufgesetzt und auf dein Scrum abgestimmt hast, geht es nun darum, Scrum auch in der täglichen Arbeit sinnvoll in OKR zu integrieren. Dazu die folgenden Punkte und Tipps:

1. OKR und Sprint Planning verheiraten
2. Arbeiten im Sprint Board mit strategischen Zielen verknüpfen
3. Sprint Reviews und Confidence Level
4. Stakeholder Management mit OKR
5. Unsicherheit managen (I) - Unscharfe Ziele
6. Unsicherheit managen (II)  - Wenn Ziele sich ändern
7. Den OKR Zyklus seriös abschließen

Um Scrum in OKR zu integrieren, ist als zweiter Schritt wichtig, dein Sprint- und OKR Planning zu Beginn eines neuen OKR-Zyklus zu synchronisieren. Das heißt, wenn ein neues OKR Intervall startet, gehst Du sowohl in ein OKR- als auch ein Sprint Planning. Da jedoch die Herangehensweisen, Fragestellungen und adressierten Gehirnbereiche jeweils andere sind, solltest Du ein wenig experimentieren, wie Du diesen beiden Events am besten miteinander verzahnst. Schließlich geht es bei OKR um eine strategische Sichtweise mit entsprechend hoher Flughöhe, wohingegen das Sprint Planning sehr detailliert und operativ ist. Hier ein paar Ideen und Anregungen.

1. Generell solltest Du immer erst das Ziel für den OKR Zyklus definieren (zumindest eine grobe Richtung), dann in das Sprint Planning gehen.

2. Du machst zuerst dein OKR Planning und mit einem Tag Pause dann das Sprint Planning.

3. Du startest das erste Sprint Planning mit den Zielen für den kommenden OKR Zyklus. Dabei sind Ziele nur frei und noch nicht als OKR ausformuliert. Während des Sprint Plannings fokussiert Du dich wie gehabt auf die Planung des vor dir liegenden Sprints. Diesen ersten Sprint nutzt ihr als Scrum Team, um OKR auszuformulieren. Die Ausformulierung als OKR dokumentiert ihr als Aufgabe im Sprint Backlog. Spätestens nach zwei Wochen solltest Du dann deinen OKR stehen haben.

Meine persönliche Präferenz ist die dritte Option. Das heißt, ich habe als Product Owner schon eine klare Idee, welche Ziele wir auf strategischer Ebene erreichen wollen und nutze den ersten Sprint, um das Ziel in OKR zu überführen. So hast Du mehr Zeit mit deinem Team wirklich gute OKR für den vor dir liegenden OKR Zyklus zu formulieren und musst nichts übers Knie brechen.

Das Sahnehäubchen bei der Integration von Scrum in OKR ist, Arbeitspakete und Aufgaben auf deinem Sprint Board mit deinen OKRs zu verknüpfen.Das heißt, Du verbindest operative Arbeitspakete mit OKR auf strategischer Ebene. Um das zu erreichen, solltest Du in jedem Sprint Planning an die laufenden OKRs erinnern, das Sprint Ziel und im Idealfall jede einzelne Aufgabe mit Objectives oder Key Results verbinden. Je nachdem, wo und wie Du dein Sprint-Backlog pflegst, gibt es auch Plugins und Erweiterungen, mit denen Du OKR in deiner Arbeitsumgebung und deinem Sprint Board verbinden kannst.

Ein weiterer wichtiger Schritt, um Scrum in OKR zu integrieren, betrifft den Umgang mit deinen Confidence Level zum Ende eines Sprints. Zum Beispiel kannst Du es zu einem offiziellen Teil deiner Demo machen, indem Du dir zum Abschluss anschaust, wie sich einzelne Key Results entwickelt haben. Auf Basis diese Checks aktualisierst Du deine Confidence Level in deiner OKR Dokumentation. Zudem kannst Du in der sich anschließenden Retro nach jedem Sprint reflektieren, wie Du Scrum noch effektiver in OKR integrieren kannst.

OKRs helfen dir beim Management deiner Stakeholder. Das ist nicht wirklich eine Technik, um Scrum in OKR zu implementieren, aber definitiv ein zusätzlicher Pluspunkt. Denn gerade in traditionellen Organisationen, in denen vielleicht nur ein paar Exoten mit Scrum arbeiten, kann Dir OKR bei deinem Stakeholder Management helfen. Dabei kannst Du folgendes tun, um Scrum und OKR ideal zu verzahnen.

1. Du erarbeitest OKR gemeinsam mit den Stakeholdern. Dabei bist Du nicht auf einer technischen Arbeitsebene, sondern auf einer rein strategischen Ebene. Das dürfte dem ein oder anderen Stakeholder sowohl von der inhaltlichen als auch der zeitlichen Taktung (nur alle drei Monate) deutlich besser bekommen.

2. Du nutzt OKR und Confidence Level als Kommunikationsmittel gegenüber deinen Stakeholdern, um dich ggf. auch vor ungewollten Einflussnahmen zu schützen. Wenn doch “Feature xy” auf einmal ganz wichtig ist, obwohl eigentlich ganz andere Ziele priorisiert wurden. Das funktioniert natürlich vor allem in Kombination mit dem ersten Punkt sehr gut.

Das heißt, OKR sind ein gutes und transparentes Stilmittel, das Du in deiner Stakeholder-Kommunikation einsetzt, um ungestört in Scrum zu arbeiten.

Die Implementierung von Scrum in OKR hat auch klare Grenzen. Dann zum Beispiel, wenn deine Vorhaben sehr explorativ und unsicher sind. Denn je explorativer deine Vorhaben, desto schwieriger ist es, messbare OKR zu formulieren. Schließlich musst Du bei völlig neuen Vorhaben mit extrem hoher Unsicherheit erst einmal durch Kundeninterviews und Prototypings herausfinden, was eigentlich vom Kunden gewollt ist. 

Beispiel: Du entwickelst und betreibst ein digitales Kundenportal, in dem Kunden wichtige Informationen finden und Tickets aufgeben. Nun möchtest Du eine Bestellfunktion integrieren, mit dem Ziel, Bestellungen komplett zu digitalisieren und teilweise zu automatisieren. Jedoch tappst Du völlig im Dunkeln, ob das vom Kunden gewollt ist und wie ihr das umsetzen könnt. Solltest Du das in dein OKR Rahmenwerk integrieren oder besser nicht?

Hier ein paar Perspektiven, wie Du mit diesen Unsicherheiten im Rahmen eines OKR Zyklus umgehst und diese beispielhafte Frage für dich beantworten kannst.

1. Du akzeptierst Unsicherheit und formulierst OKR aus der idealen Perspektive. Damit haben deine OKR einen hohen Unsicherheitsgrad.

2. Du lässt diese Vorhaben aus dem OKR Rahmenwerk heraus. Das heißt, Du nimmst Vorhaben und entsprechende Ziele erst dann in das OKR Rahmenwerk, wenn Du auf Basis von ersten Interviews und Prototypen Anzeichen hast, dass dein Plan funktionieren kann. Experimente und erste Prototypen managst Du ganz normal im Scrum Zyklus.

3. Du gehst auf eine Metaebene und definierst nicht die konkreten Outcomes, sondern die Anzahl der Experimente und Prototypen als OKR. Dieser Ansatz nutzt sich jedoch irgendwann ab, weil sich OKR schnell wiederholen.

Meine präferierte Vorgehensweise ist die zweite, d.h. diese explorativen Vorhaben, erst dann in das OKR Rahmenwerk zu integrieren, wenn Du verstanden hast, dass entsprechende Leistungsmerkmale vom Kunden gewollt und auch realisierbar sind. 

Für jemanden, der Scrum denkt, kann es ziemlich befremdlich sein, Ziele für drei Monate zu formulieren. Schließlich kann sich auf diesem Weg doch so viel ändern und Neues passieren. Auch hierzu ein paar Tipps, wie Du mit dieser Unsicherheit umgehst, um Scrum sinnvoll in OKR zu integrieren. 

1. Wenn Du auf dem Weg lernst, dass der OKR nicht mehr erstrebenswert ist, dann streichst Du den OKR. Das solltest Du jedoch zum Anlass nehmen, kritisch zu hinterfragen, ob Du den OKR vielleicht zu früh formuliert und nicht ausreichend Zeit in eine gute Exploration investiert hast. 

2. Wenn Du während des OKR Prozesses merkst, dass sich andere Metriken besser eignen, um das angestrebte Objective zu erreichen, dann ergänzt Du diese einfach als entsprechende Key Results.

3. Wenn neue Ziele auftauchen, (z.B. weil Du durch Kundeninterviews und Prototypen ein neues Leistungsmerkmal erschlossen hast), dann integrierst Du diese auch kurzfristig in deinen OKR Zyklus. Das machst Du jedoch bitte mit Bedacht und Augenmaß. Denn wenn diese ad hoc Updates zur Regel werden, dann führst Du die Arbeit mit OKR irgendwann ad absurdum.

Das OKR Rahmenwerk sollte kein Gefängnis sein und gleichzeitig solltest Du nicht vogelwild damit arbeiten. 

Der letzte Schritt Scrum in OKR zu implementieren ist, den OKR Zyklus seriös abzuschließen. Genau wie Du das OKR Intervall mit einem gemeinsamen Planning gestartet hast, veranstaltest Du zum Abschluss deines OKR Zyklus eine gemeinsame Review. Zusätzlich zu deiner Scrum Demo gehst Du in eine inhaltliche Betrachtung deiner OKR und bewertest den Grad der Zielerreichung. Google nennt diesen Vorgang auch “Grading”. Dabei bewertest Du jedes Key Result, vergleichst SOLL und IST Zahlen und gibst deinem OKR einen abschließenden Zielerreichungsgrad. Das gibt Dir wiederum Rückschlüsse, wie gut Du mit deiner Strategie eigentlich vorankommst.

• Zielerreichung < 50%: Entweder sind deine Ziele zu ambitioniert oder Du lässt dich zu sehr von deinen Ziele ablenken. 
• Zielerreichung > 70%: Du hast ein Rockstar Team oder deine Ziele sind nicht ambitioniert genug. 

Das heißt, ein guter Zielerreichungsgrad liegt zwischen 50 - 70%. Zum Abschluss deines OKR Zyklus gehst Du dann in eine Retrospektive und fragst kritisch, wie ihr die Implementierung von Scrum in OKR noch weiter verbessern könnt.

Zum Abschluss der Implementierung von Scrum in OKR noch ein paar allgemeine Hinweise. Denn es kommt schnell vor, dass man sich in methodischen Details verliert, statt sich immer wieder vor Augen zu führen, worauf es bei der Implementierung von Scrum in OKR denn eigentlich ankommt.

1. Mach es einfach. Viele OKR Implementierungen schießen über das Ziel hinaus, sind aufgeblasen und bürokratisch.
2. Scrum und OKR dienen deiner Organisation, nicht umgekehrt. Das heißt, die Rückmeldungen der Teams und Mitarbeiter sind ein wichtiger Gradmesser für eine wirksame Implementierung von Scrum in OKR. 
3. Gesunder Menschenverstand hat immer Vorrang.
4. Es geht um die Realisierung von Customer und Business Value.
5. Scrum und OKR helfen dir, Unsicherheit und Risiko zu managen. OKR auf einer strategischen, Scrum auf einer operativen Ebene.

Scrum und OKR sind ein starkes Doppel. Weil beide Rahmenwerke sehr ähnlich und doch so unterschiedlich sind. Mit OKR behältst Du das große Ganze im Auge, kannst Scrum-Teams rund um Product Owner, Entwickler und Stakeholder auf das “big picture” ausrichten. Dagegen hilft dir Scrum, konkrete Arbeitspakete zu liefern, den alltäglichen Wahnsinn zu managen und in kleinen Schritten immer wieder zu schauen, ob Du auf einem guten Weg bist. Darüber hinaus nutzt dir OKR vor allem im Management deiner vielen Stakeholder und hält dir als Product Owner den Rücken frei.

Viel Erfolg dabei.