OKR und Produktentwicklung
Die Vorteile agiler Ziele
Als Agile Software Factory ist es uns wichtig, die Grundsätze des agilen Arbeitens bei jedem Projekt einzuhalten. Das beinhaltet beispielsweise, dass wir unsere Kunden als Partner verstehen und wir stets flexibel auf Veränderungen reagieren können.
Ein weiterer wichtiger Aspekt, wenn wir Software für unsere Kunden entwickeln, ist Transparenz. Den Umfang eines Projekts definieren wir in einem für alle einsehbaren Backlog. Zu jedem Zeitpunkt haben Kollegen, Vorgesetzte und Auftraggeber Zugriff auf die User Stories und können sich über den aktuellen Status informieren. So sind alle Beteiligten immer auf dem gleichen Stand. Doch wie messen wir eigentlich, ob wir letztlich die Ziele unsere Auftraggeber erreichen?
Um Zielerreichung messen zu können, gibt es verschiedene Methoden. Ein bekanntes Modell ist das der SMART-Ziele. Hierbei wird verlangt, dass die Ziele
- spezifisch
- messbar
- akzeptiert
- realistisch und
- terminiert
sind. Diese Methode nutzt man allerdings eher bei persönlichen Zielen. Jahresziele werden oft so definiert. Diese gelten dann zwischen Vorgesetzten und Mitarbeitern, wobei die einzelnen Vorgaben nur diesen beiden Akteuren bekannt sind. Solche Zielvereinbarungen sind nicht für die Messung von Zielen in der agilen Produktentwicklung geeignet. Denn sie sind starr und häufig intransparent.
Mehr Transparenz mit OKR
Um die Ziele nach agilen Maßstäben zu gestalten, verwenden wir OKR. Die Abkürzung steht dabei für „Objectives and Key Results“. Man unterscheidet hier in qualitative Objectives und quantitative Key Results.
- Objective: Was möchte ich erreichen?
- Key Result: Was muss ich dafür tun und wie ist das messbar?
In der Praxis sieht das dann so aus:
Objective: Ein Kölner landet auf dem Mond
Key Result 1: Führe bis 1. Oktober 2020 Eignungstests mit 10 Astronauten-Kandidaten aus Köln durch
Key Result 2: Finde eine Software-Firma aus Köln für die Entwicklung einer Astronauten-App bis 1. November 2020
Key Result 3: Führe bis 1. Februar 2021 fünf erfolgreiche Teststarts mit dem Mond-Shuttle durch
Der für uns wichtigste Unterschied zu anderen Zielmessmethoden ist: OKR können unternehmensweit offen eingesehen und entsprechend agiler Grundsätze iterativ (üblicherweise quartalsweise) angepasst werden.
Als Software-Dienstleister machen wir uns Ziele der Kunden zu eigen: Wer bereits an einem der lise Konzeptionsworkshops teilgenommen hat, kennt die Vision-Board Methode, bei der wir sehr früh im Produktentwicklungsprozess eine Produktvision erarbeiten. Diese hilft uns bei der darauffolgenden Erarbeitung des Product-Backlogs. Wir haben jedoch festgestellt, dass die gedankliche Lücke zwischen der relativ abstrakten Produktvision und den operativen Backlog-Items zu groß ist. Genau hier können OKR helfen!
Vorteile von OKR
Durch die transparente Darstellung aller Ziele können Mitarbeiter teamübergreifend Synergien schaffen. Bei sich überschneidenden Zielen arbeitet man gemeinsam an deren Erfüllung. Und Ziele, die gegenläufig sind, können augenblicklich entdeckt werden. Damit lösen sich Konflikte, bevor sie zu Problemen führen.
Teamübergreifendes Arbeiten an Zielen stärkt dabei das Vertrauen untereinander und schafft Zusammenhalt. Darüber hinaus können so interdisziplinäre Skills aufgebaut werden. Etwa wenn man sich bei Teamzielen zusammen mit Kollegen in Bereiche vorwagt, in denen man bisher nicht viel Erfahrung gesammelt hat.
Außerdem können einzelne Backlog-Items der Entwickler auch mit den jeweiligen Zielen verknüpft werden. Beide sind transparent nachzuvollziehen und zahlen auf die Unternehmens- bzw. Produktziele ein. Dadurch wird auch viel klarer, wohin man will und welchen Sinn man stiftet, der "Purpose" wird sichtbarer. Das unterstützt wiederum die Motivation. Ebenso wird in regelmäßigen, kurzen Abständen die bisherige Zielerreichung untereinander besprochen. So sind alle Beteiligten immer auf dem gleichen Stand.
Zusätzlich nimmt ein Kollege oder eine Kollegin die Rolle des OKR-Masters ein und hilft bei der Formulierung der Objectives und Key Results. Dieser wahrt den Überblick über die Ziele und gibt dem ganzen Konzept Halt. In der Summe gestaltet sich das Erreichen der gesetzten Ziele so deutlich effizienter.
8 Do's and Don'ts der OKR
| Don't | Do |
|---|---|
| Vage Formulierungen: „Bessere Software entwickeln“ kann nicht gemessen werden. | Genaue Sprache verwenden und messbare Key Results formulieren. |
| Ziele von oben herab diktieren. | Ziele zusammen mit den Mitarbeitern bestimmen. Dabei Unternehmensziele im Blick behalten. |
| Nur individuelle Ziele festlegen. | Sowohl Individuelle als auch Teamziele festlegen. |
| Zu viele Objectives „sammeln“. | Aktiv archivieren und Übersicht bewahren. |
| Auf die letzten Prozente optimieren. | Sich neuen Aufgaben widmen: „Wo will ich was erreichen und verändern?“ |
| Zielerreichung erst am Ende des festgelegten Zeitraums überprüfen. | Regelmäßig den Status der Ziele besprechen. |
| Eine fremde Vorlage blind als Masterplan übernehmen | Selbst anfangen, Scheitern zulassen, lernen. |
| Ja/Nein Beschreibungen in den Key Results. | Relative oder absolute Zahlen verwenden. |
Produktentwicklung und OKR bei der lise
Im Vorfeld definierte Ziele sind für uns ein wichtiger Bestandteil bei der Zusammenarbeit mit Kunden. Schließlich wollen wir nur das tun, was zur Erreichung der Kundenziele beiträgt. Der Auftraggeber wiederum will den Projektstatus kennen und die Arbeit anhand der Ziele steuern.
Mittlerweile benutzen viele Unternehmen für die wir arbeiten agile Arbeitsmethoden. Denn sie wissen: Produktentwicklung funktioniert so einfach besser. Für uns ist das äußerst hilfreich. Wir orientieren uns an den gleichen Prinzipien und im Idealfall am gleichen Zielsystem - OKR. So können die ganzen Vorteile agilen Arbeitens ausgespielt werden.
Um die Vorteile zu verstehen, möchte ich zuerst ein Negativbeispiel anführen:
Kunden, die uns als Dienstleister für ihre Software beauftragen, skalieren über ihre eigentliche Unternehmensgröße hinaus. Wir, die externe Ressource, sollen eine Aufgabe erfüllen, die intern nicht bearbeitet werden kann. Oft stellt dann der Auftraggeber trotzdem einen Product Owner / Produktmanager selbst. Dieser hat die Aufgabe, das Projekt zu führen - zusätzlich zu seinen eigentlichen Aufgaben im Unternehmen. Obwohl man mit der Beauftragung des Dienstleisters vorhat, das eigene Unternehmen zu entlasten.
Das Problem dabei: Die Aufgabe eines PO ist zeitintensiv. In der Regel sollte die Arbeitszeit, die dieser Führungsrolle gewidmet wird, nicht unter 20 Stunden / Woche liegen. Damit kein Leerlauf entsteht, muss die Abstimmung zwischen PO und Entwickler tagesaktuell sein. In der Praxis führt diese Konstellation zu Engpässen und Zeitdruck. Einher gehen damit langsamere Entwicklungsfortschritte bei uns und Zielkonflikte beim Kunden.
OKR und der Produktmanager (PO)
Wenn Kunden agil arbeiten und bereits im Vorfeld über die Produktvision und die damit verbundenen OKR sprechen, kann die Produktentwicklung deutlich dynamischer gestaltet werden. Objectives und Key Results fungieren dann als Bindeglied zwischen der Produktvision und dem Backlog. So ergeben sich die User Stories fast von selbst.
Unter diesen Voraussetzungen kann der Auftraggeber den PO auch mit einem Mitarbeiter des Dienstleisters besetzen, der sich einfach an den OKR orientiert. Die zuvor formulierten OKR des Auftraggebers versetzen uns also in die Lage, die Aufgaben aus den Backlog-Items genau, effizient und flexibel umzusetzen. Eben agil.
„Objectives und Key Results fungieren als Bindeglied zwischen der Produktvision und dem Backlog.“
Weil es zur Methode OKR dazugehört, sich über den Status der jeweiligen Ziele regelmäßig auszutauschen, bleiben wir kontinuierlich in Kontakt. So kann man die Ziele immer wieder angleichen und die Erreichung partnerschaftlich vorantreiben.
Im Gegensatz zu starren Zielvereinbarungen kann man bei OKR jederzeit flexibel auf neue Wünsche und Vorstellungen des Kunden reagieren und diese zeitnah und exakt umsetzen. Letztlich führt das zu einer hohen Taktung, so dass Software-Features in möglichst kurzen Abständen fertig gestellt werden. Auch wird der der designierte Projektmanager des Kunden entlastet und kann sich seinen ursprünglichen Aufgaben widmen.
Möchte der Kunde den Produktmanager dennoch selbst besetzen, lässt sich durch das gemeinsam gelebte Zielsystem auch eine Aufteilung der PO-Aufgaben festlegen. Wir stellen dann einen sogenannten Proxy-PO, der mit seiner Erfahrung und Expertise dem Produktmanager des Kunden zur Seite steht. Damit lässt sich die Aufgabenverteilung optimieren, um gemeinsam mehr zu erreichen. Und das immer zielgerichtet!
Tools für OKR - „Sei kein Tooligan!“
Mit welchen Tools hält man die OKR am besten fest? Die Möglichkeiten sind jedenfalls vielfältig. Man kann eine Google Tabelle aufsetzen, ein gemeinsam genutztes Excel-Sheet auf dem Cloud-Speicher verwalten, oder aber auch eine zusammen genutzte Intranet-Seite, zum Beispiel via Sharepoint, verwenden. Inzwischen gibt es sogar eine spezialisierte Open-Source OKR-Software namens BurningOKR.
Hauptsache ist, man kann gemeinsam auf die Inhalte zugreifen. Meine Empfehlung: Nicht zu viel Aufwand in das Tool stecken, sondern eher in die Ausarbeitung der eigentlichen Ziele. Beim Aufsetzen des passenden Tools helfen wir natürlich gern.
Bei uns haben OKR übrigens auch die persönlichen, smarten Ziele abgelöst. Das verhindert, das einmal festgelegte Ziele über Monate in der Schreibtischschublade verschwinden. Vorbei sind die Zeiten, in denen man kurz vor Jahresende wie verrückt an der Erreichung der fast in Vergessenheit geratenen Ziele gearbeitet hat.
PS: In unseren Schulungen der „lise Academy“ geben wir unser Wissen zum Thema OKR und Projektmanagement weiter und vermitteln alle Inhalte, die man für zielgerichtetes, agiles Arbeiten benötigt. Melden Sie sich bei mir!