OKRs UND PRODUktMANAGEMENT VERKNÜPFEN

Die Verbindung des agilen Zielemanagements mittels OKRs (Objectives and Key Results) und Produktmanagement Methoden ist ein naheliegender Gedanke. OKRs unterstützen Agilität in der gesamten Organisation und ermöglicht mehr agiles Arbeiten somit über die IT- und Produktabteilungen hinaus. Wo Argumente auf dem Papier sofort überzeugen, zeigt die Praxis jedoch oft schnell, dass die Alltagsverknüpfung von Methoden wie OKRs (agile Ziele) und  Scrum oder anderen oft nicht ganz einfach sind. Kein Handbuch beschreibt, wie OKR Sets und Epics zusammen spielen, was OKRs für die Product Roadmap bedeuten, welche Meetings zusammen passen oder wie gute OKR Sets für eine Product Discovery aussehen.

In der Zusammenarbeit mit Tim Herbig als Product Management Experten ist eine Zusammenführung entstanden, die genau diese Fragen des Alltags beantworten soll. Eine Englische Version dieses Artikels findet ihr auf seiner Website.

OKRs ist ein Führungs-Tool, dass den Fokus für die ganze Organisation auf die Umsetzung der richtigen Dinge sicherstellt. 

Durch das quartalsweise Formulieren von Objectives (Zielen) und Key Results (Erfolgs-Messkriterien) wird der nächste Schritt als eine Art Mini-Vision für alle greifbar gemacht. OKR Sets beschreiben so das Warum Dinge getan werden sollen. Sie gelten oft quartalsweise für die gesamte Organisation. Davon abgeleitet entstehen außerdem OKR Sets für alle Bereiche und Teams, die den Anteil der jeweiligen Einheiten zur Erreichung des Organisations-OKR-Sets abbilden.

Objectives sind die qualitative Beschreibung der Ziele, die inspirierend, im Quartal und unabhängig vom jeweiligen Team erreichbar sind.

Key Results machen als wichtigen Bestandteil die Objectives messbar. Weil sie quantifizieren, wie die optimale Zielerreichung aussieht, schaffen sie Klarheit für alle Beteiligten. Das können zum Beispiel Messkriterien in Bezug auf Umsatz, Wachstum, Nutzer, Qualität oder Performance sein.

Durch die Art und Weise der Zieldefinition und des Monitorings werden unter anderem Transparenz, Synchronität, Agilität und Engagement in der Organisation gestärkt. Alle haben so eine gemeinsame Orientierung, die jedes Quartal neu justiert wird. Die Vorteile dieses Ansatzes im Vergleich zu individuellen Bonusvereinbarungen oder 3-Jahresplänen liegen schnell auf der Hand.

Eine ausführliche Beschreibung von OKRs als Ansatz findest du in diesem Artikel. 

Um die Bedeutung von OKRs für agile Produktteams zu verdeutlichen, schauen betrachten wir das Beispiel der SaaS-Analytics Firma Analytico an. Analytico möchte mit Software lernende Organisationen ermöglichen. So könnte ein OKR Set für das folgende Quartal aussehen:

• Objective Q3: Neues Kundensegment “Online Marketers” gewinnen
• Key Result 1: 100.000 neue Online Marketer Kontakte
• Key Result 2: 50.000 € Umsatz mit Kunden aus diesem Segment
• Key Result 3: Durchschnittl. Kundenzufriedenheit im Segment von 30 auf 75% steigern

Nach der Formulierung folgt die Aufgabenplanung - das Was getan werden soll. In diesem Fall könnten Maßnahmen wie eine Online Marketing Kampagne oder ein Projekt zur Produktverbesserung einige von vielen Möglichkeiten sein, die Key Results zu erreichen.

Zwischen dem Beginn und dem Ende eines Quartals, an dem das Ziel erreicht werden soll, liegen allerdings viele Tage, E-Mails, Meetings, Arbeitspaketplanungen - also die vielen kleinen Entscheidungen des Arbeitsalltages. Sind hier die OKR nicht jedem Mitarbeiter präsent, können sie nicht als Entscheidungshilfe für den besten Weg zur Zielerreichung dienen.

Deswegen ist es ratsam, OKR Sets nicht nur quartalsweise zu Formulieren, in einem Dokument abzulegen und erst am Ende des Quartals zur Bewertung wieder hervorzuholen. Ganz im Gegenteil: OKRs müssen zum Leben erweckt und für jeden sichtbar in den Arbeitsalltag integriert werden. Nur wer seine OKR Sets kennt, kann auch seine Arbeit auf sie ausrichten. Sind OKRs zum Beispiel bei Entscheidungsprozessen in einem Teammeeting oder einer Sprintplanung sichtbar, können alle Aufgaben exakt nach den OKRs priorisiert werden.

Falls du noch gar nicht mit OKRs arbeitest, aber noch Argumente suchst, damit ihr von einer reinen Feature-Factory hin zu wirksamer Produkterstellung kommst, schau doch gerne in dieses Video:

Um Produktmanagement mit agilen Zielen zu vergleichen, beziehungsweise zu zusammenzuführen werfen wir zunächst noch einen kurzen Blick auf dessen Definition. Festzuhalten ist zunächst, dass es wie mit vielen modernen Themen in diesem Sinne keine einheitliche Definition gibt. Bekannte Methoden für die agile Entwicklung von Produkten wie Scrum sind zwar sehr detailliert ausformuliert, beinhalten jedoch hauptsächlich den konkreten Umsetzungsaspekt und weniger die Vorstufen der Planung.

In unserem Falle wollen wir den Produktmanagement Prozess in 3 Schritten beschreiben. Der Vergleichbarkeit halber benutzen wir hier die Englischen Begriffe:

Product Planning - Langfristiger Ausblick mit Themen-basierten Roadmaps

Product Discovery - Identifikation möglicher Lösungen für Kundenprobleme

Product Delivery - Umsetzung der priorisierten Produktlösung in iterativen Schritten

Typischerweise ist in Organisationen eine gewisse Vorausplanung der Produktentwicklung getrieben durch Stakeholder wie große Kunden oder Investoren notwendig. Deshalb gibt es oft sogenannte Jahres-Roadmaps, die oftmals termingetrieben bestimmte Themenblöcke der Produktentwicklungen für die Zukunft oder eben mindestens das nächste Jahr im Voraus skizzieren. In Zeiten von einfacher Vorhersage-Möglichkeit und nach Wasserfall-Methodik organisierten Projekten war dies ein passendes Instrument.

In einem agilen Umfeld jedoch soll jederzeit auf neue Erkenntnisse von Kundenbedürfnissen oder anderen Einflüssen aus der Umfeld reagiert werden können. Deswegen ist es auch im Planning notwendig, flexiblere Formen von Roadmaps zu benutzen. Der Unterschied zur klassischen, zeitbasierten Roadmap liegt in der Detailtiefe. Je näher ein Thema auf der Roadmap rückt, je detaillierter ist dieses bereits bekannt und beschrieben. Je weiter weg ein Thema ist, je unkonkreter ist es beschrieben und erfährt nur eine zeitliche Einordnung in die groben Kategorien "bald" und "später".

Eine Herleitung dieses Ansatzes findest du zum Beispiel im Video von C. Todd Lombardo in seinem Talk im Rahmen der Mind the Product San Francisco 2018:

Mit einer Themen-basierten Roadmap wissen alle grob, eben welche Themen in der Zukunft bearbeiten werden. Konkretisiert werden diese dann in der Discovery-Phase. Hier findest du heraus, was entwickelt werden soll, oder auch welche Lösungsansätze für Kundenprobleme möglich sein können.

Eine Discovery enthält mehrer iterative Schritte, die auch hier wieder in jedem Produktumfeld anders gelebt werden. Typischerweise sind Auftragsklärung, Erforschung der Nutzerprobleme, Ideenfindung, Kreation von Prototypen, Validierung und weiterer Feinschliff zum Beispiel mittels Impact Mapping Teilschritte. Das Ergebnis ist ein mit echten Kundenbedürfnissen abgeglichenes Produktkonzept in Form eines Epics, dass entweder verworfen wird oder aber in der nächsten Phase (Delivery) in ein echtes Produkt umgesetzt wird.

Die Umsetzungsphase nimmt je nach Produkt und Team oft die meisten Ressourcen in Anspruch. Jetzt geht es um echte Detailarbeit und das Erschaffen eines realen Produktes. Ein gesamtes Team von Produktmanagern, Designern und Entwicklern arbeitet bei der Anwendung von Methoden wie Scrum oder Kanban in kurzen Sprints an der Produkterstellung.

Ein Sprint dauert typischerweise zwei Wochen. In dieser Zeit werden auf der einen Seite die für diese Zeit geplanten Aufgaben in Form von User Stories und Tickets umgesetzt werden. Gleichzeitig wird der nächste Sprint durch das Beschreiben von Funktionalitäten und Design vorbereitet.

Am Ende des Sprints werden in der Sprint-Review die erstellten Ergebnisse präsentiert. In der anschließenden Retro reflektiert das Team die grundsätzliche Zusammenarbeit und mögliche Potentiale gemeinsam. 

Inhaltlich wird bei agilen Methoden des Produktmanagements das “Was” organisiert und damit die konkreten Aufgabenblöcke für die Produktweiterentwicklung organisiert.

Ohne eine Verbindung der einzelnen Aufgaben zu den übergeordneten Firmenzielen kann schnell der Fokus verlorengehen. Produktentwicklung wird dann schnell zum Selbstzweck, gerne auch #Featurefactory genannt. 

Zusammengefasst kann man die beiden ausführlicher beschriebenen Methoden wie folgt beschreiben: 

Die Unternehmens-Vision (oder -Strategie) und davon abgeleitet die Produkt-Vision sind das langfristige “Warum”. Warum existiert mein Unternehmen? Wofür stehe ich? Was möchte ich mit meinem Produkt langfristig erreichen? Davon lassen sich die quartalsweisen OKR Sets ableiten, die eine Art Mini-Warum darstellen. 

Demgegenüber befindet sich das “Was”, das Produktmanagement mit seinen konkreten Themes, Epics, User Stories und letztendlich Tasks. Themes und Epics umfassen dabei oft einen mittelfristigen Zeithorizont. Sie beschreiben meist größere Themenblöcke oder Features, die einen längeren Entwicklungszeitraum benötigen. User Stories und Tasks hingegen haben kürzere Zeiteinheiten, weil sie innerhalb der zweiwöchigen Sprint bearbeitet werden sollen.

So spielen zum Beispiel OKRs und Produktmanagement für die Softwarefirma Analytico zusammen:

Das formulierte Objective "Neues Kundensegment “Online Marketers gewinnen" gibt Orientierung für den folgenden Product Management Prozess.

Die Discovery-Phase hat zum Ziel, konkrete Kundenprobleme und mögliche Lösungen für diese zu identifizieren. Das Ergebnis, zum Beispiel das Feature "Kostenloser Lead Magnet Test", wird als Epic beschrieben.

In der Delivery-Phase bespricht und bearbeitet das Product Team dann gemeinsam in Sprints konkrete User Stories, wie die Erstellung einer Facebook Schnittstelle. 

OKRs und Produktmanagement sind besonders eng verbunden bei den zeitlich mittelfristigen Artefakten des Produktprozesses. Themes und Epics sollten deswegen auf jeden Fall mit den aktuellen OKR Sets und OKR Prozessen synchronisiert werden.

Gibt es bereits vorhandene Themes/ Epics im Themenpool, priorisiert das OKR Set, welche dieser vorhandenen Artefakte aus der Roadmap als nächstes bearbeitet werden sollten. Gibt es noch keine Themes/ Epics, die auf die Erfüllung des aktuellen Quartals-OKR Sets einzahlen, gibt das OKR Set die Richtung für eine neue Discovery-Phase vor. Damit sind indirekt auch User Stories und Tickets mit den jeweils aktuellen OKR Sets synchronisiert.

Wird ein Epic dann in Form von User Stories / Tickets in einem Sprints bearbeitet, sollten abgeschlossene User Stories in erheblichem Maße die Key Result Fortschrittsmessung voranbringen. User Stories, die keine Wirkung auf diesen Kriterien erzielen sind entsprechend wirkungslos und erfordern eine Überarbeitung oder das Andenken ganz anderer Wege. 

OKR Sets werden üblicherweise in einer Tabelle oder in einem spezifischen OKR Tool festgehalten und gemonitored.

Sie können mit Epics und User Stories oder Tickets verbunden werden, in dem man an jedes dieser Artefakte ein (Pflicht-)Feld einfügt. In diesem Feld wird dann das OKR Set, auf das das Artefakt einzahlt mit Text oder als Nummer genannt.

Es kann auch immer Tickets geben, die keinem konkreten OKR Set zugeordnet werden können, da die dringend notwendige Aufgabe vielleicht zu Beginn des Quartals noch nicht bekannt war oder einfach eine gewisse Notwendigkeit von Maintenance-Aufgaben immer besteht. Dies ist überhaupt kein Problem, sollte aber trotzdem transparent gemacht werden und vor allem bei der OKR Definition durch eine Art geblockte Ressourcen für Maintenance berücksichtigt werden. Sind zum Beispiel immer 20% der Ressourcen dafür eingeplant, kann auch nur mit 80% der Ressourcen für die OKR Erreichung geplant werden.

Das Management von Zielen und Aufgaben in einem Tool zu verbinden ist häufig nicht empfehlenswert. Es gibt zwar beispielsweise OKR-Plugins für Jira, aber meist arbeitet nicht die gesamte Organisation mit nur einem Tool als Aufgabenmanagement.

Über die Verbindung von OKR und Epics und deren abgeleiteter User Stories ist bereits wichtige Grundlage für das erfolgreiche Zusammenwirken von Zielen und Aufgaben gelegt.

Die Erreichung der mit OKRs quartalsweise formulierten Ziele kann vor allem dann erfolgreich werden, wenn OKR Sets tatsächlich in alle täglichen und wöchentlichen Entscheidungsprozesse der Produktentwicklung integriert werden. Das heißt in jedem Stand-Up Meeting, in jeder Review, in jedem Planning, etc. sollten sie das sichtbare Priorisierungstool für Entscheidungen sein.