Ursachenforschung im agilen Umfeld OKRs nicht erfüllt – woran kann es liegen?

OKRs nicht erfüllt – woran kann es liegen?

Eine Erfüllungsquote von null Prozent beim OKR Review: Wie kann das passieren trotz erfahrener Projektteams? Autor Peter Rubarth hat sich auf Spurensuche begeben und acht Faktoren gefunden, auf die Sie bei Ihren Projekten achten können.

Management Summary

Download PDFDownload PDF

Ursachenforschung im agilen Umfeld OKRs nicht erfüllt – woran kann es liegen?

OKRs nicht erfüllt – woran kann es liegen?

Eine Erfüllungsquote von null Prozent beim OKR Review: Wie kann das passieren trotz erfahrener Projektteams? Autor Peter Rubarth hat sich auf Spurensuche begeben und acht Faktoren gefunden, auf die Sie bei Ihren Projekten achten können.

Management Summary

Wir empfehlen zum Thema Agile
1 Tag
26.06.2024
795,00,-
So gelingen Veränderungen unter hoher Auslastung

In diesem Workshop betrachten wir verschiedene Wege, wie Unternehmen Veränderungen unter Vollauslastung des Systems erfolgreich einleiten und umsetzen können. Mehr Infos

Ein Technologie-Startup hat seinen Markt gefunden. Es wächst und wächst. Das Unternehmen steht vorn in den Ranglisten und wird als potenzielles Unicorn gehandelt.

Die Belegschaft von ca. 500 Mitarbeiter:innen ist jung, international und exzellent ausgebildet. Agile Softwareentwicklung ist der Standard. In den ca. 20 Produktentwicklungsteams gibt es niemanden, dem man die Idee von iterativ-inkrementellem Vorgehen erklären muss. Die meisten Entwickler:innen kennen es nicht anders. Die Produkte sind Everything as a Service (XaaS) Lösungen in einem hoch regulierten Umfeld. Sie ermöglichen es den B2B-Kund:innen, Dienstleistungen per Softwareschnittstelle in ihre eigenen digitalen Produkte einzubinden, ohne sich mit den regulativen Details auseinandersetzen zu müssen.

Ein Beispiel für diese Art von Produkt ist eine Softwareschnittstelle, um als Betreiber einer Website datenschutzrelevante Datenverarbeitung an eine/-n Dienstleister:in auszulagern. Der/die Dienstleister:in übernimmt die Datenverarbeitung und stellt die Einhaltung als Vorschriften sicher.

Die Bewältigung des Wachstums ist ein großes Thema. Insbesondere die Serviceabteilungen stoßen bei der Bewältigung des exponentiellen Wachstums an ihre Grenzen. Ihre Rolle ist – vergleichbar mit einem Backoffice –, die in Zusammenhang mit der Nutzung der XaaS-Produkte anfallenden Geschäftsvorfälle abzuwickeln. Es ist offensichtlich, dass das steigende Arbeitsaufkommen mit zusätzlichen Mitarbeiter:innen alleine nicht zu bewältigen ist. Der manuelle Aufwand muss erheblich reduziert werden, um die schnell steigenden Volumina mit ungefähr gleichbleibender Mitarbeiter:innen-Anzahl zu stemmen.

Aus diesem Grund wurde ein Projekt zur Automatisierung ausgewählter interner Prozesse initiiert. Die fraglichen Prozesse sind einerseits besonders zeitaufwändig. Andererseits scheinen sie vergleichsweise einfach automatisierbar zu sein. Die Grundidee hinter dem Projekt ist, dass bisher notwendige manuelle Schritte durch neue Funktionalität des digitalen Produkts ersetzt werden.  

Bei dieser Art von Automatisierungsprojekten stellen die Serviceteams einen internen Auftraggeber dar und bringen ihre fachliche Expertise ein. Die Produktentwicklungsteams, zusammengesetzt aus Softwareentwickler:innen und Product Ownern, verantworten die konzeptionelle und technische Entwicklung bestimmter XaaS-Produkte.

Die Produktentwicklungsteams sind für jegliche technische Weiterentwicklung der XaaS-Lösungen zuständig. Insbesondere bestehende und neue B2B-Kund:innen haben eine lange Liste mit nachgefragten zusätzlichen Features. Es gibt dementsprechend immer weitaus mehr Nachfrage als Kapazität vorhanden ist. Daher ist ein Platz auf der Roadmap der Produktentwicklungsteams sehr wertvoll. Für die Serviceteams ist diese Situation schwierig, denn sie sind angewiesen auf die Produktentwicklungsteams, konkurrieren aber mit externen, umsatzbringenden Anfragen.

Die OKR Review - ein Desaster

Für die Ausrichtung der Teams an den Unternehmenszielen wurden vor mehreren Jahren "Objectives and Key Results" (OKRs) als Zielmanagement-Methode eingeführt.

Vor diesem Hintergrund findet die OKR Review einer Serviceabteilung statt. Ich begleite die Abteilung seit einigen Monaten als Agile Coach bei Themen der Teamentwicklung und Prozessoptimierung. Eines dieser Themen ist die Ausgestaltung des OKR-Prozesses in der Abteilung.

Aus Agile Coach Perspektive bin ich sehr zufrieden mit dem Verlauf des Termins. Die anwesenden Teamleiter stellen ihre Ergebnisse vor. Die Atmosphäre ist konzentriert, offen und wertschätzend.

Ich horche auf, als bei einem Team 0% Zielerreichung festgestellt wird. Inhalt dieses Key Result war eine Produktoptimierung mit dem Ziel, die Effizienz im Team um wenigstens 50% zu steigern. Die Fertigstellung der geplanten Funktionalität wurde mehrfach verschoben und ist inzwischen mehrere Monate in Verzug. Ein konkreter Liefertermin ist nicht klar.

Ohnehin ist das Vertrauen in die Einhaltung derartiger Zusagen nach den Erfahrungen der Vergangenheit gering. Da die Personalplanung des Serviceteams auf den ursprünglichen Terminzusagen und den erwarteten Einsparungen basiert, ist das Team an der Belastungsgrenze. Das Arbeitsaufkommen wächst kontinuierlich und die Personalstärke reicht nicht mehr aus.

Objectives and Key Results

"Objectives and Key Results" (kurz OKRs) ist ein Ansatz zur Formulierung von Zielen, welche in den 1980er Jahren von Andrew Grove bei IBM entwickelt wurde. Populär wurden OKRs durch den Einsatz bei Google.

Eine zentrale Idee von OKRs ist die Zweiteilung in Objectives und Key Results. Mit Objectives werden qualitative Ziele beschrieben. Die zu den Objectives gehörenden Key Results beschreiben Vorhaben, von deren Umsetzung man sich eine Erreichung der Objectives verspricht. Die Key Results müssen dabei so formuliert sein, dass eine objektive und quantitative Bewertung der Umsetzung möglich ist.

OKRs werden in regelmäßigen Zyklen gesetzt und die Ergebnisse reviewt. Ein Zyklus dauert üblicherweise drei Monate. Die Auswertung erfolgt in der Form, dass für jedes Key Result die Erreichung zwischen 0 und 100% festgestellt wird. Dabei entsprechen 70% Zielerreichung den realistischen Erwartungen. Dieses Vorgehen soll die Setzung von ambitionierten Zielen fördern, um so Ergebnisse jenseits der ursprünglichen Erwartungen zu ermöglichen.

Aus demselben Grund soll die Erreichung von OKRs nicht mit Bonuszahlungen oder anderen Anreizsystem verknüpft werden, um ein „Gaming“ zu vermeiden.

Anders als etablierte Zielesysteme kaskadieren OKRs nicht. Ziele werden nicht herunter gebrochen. Stattdessen formulieren selbstorganisierte Teams ihre Ziele selbst und justieren die Zielformulierungen im Dialog miteinander und mit der Geschäftsführung. Durch diesen Dialog werden Unklarheiten und gegenseitige Abhängigkeiten aufgedeckt und die Ausrichtung aller Teams an dem gemeinsamen Unternehmenserfolg kann verbessert werden.

OKRs haben, richtig eingesetzt, den Vorteil, dass sie dezentrale Teamstrukturen ermöglichen. Sie helfen bei der Koordination, ohne einzuengen. OKRs integrieren sich gut mit anderen agilen Vorgehensweisen und ergänzen diese um einen mittelfristigen Planungshorizont.

Der Auftrag: Ursachenforschung zum OKR-Desaster

Nach der OKR Review erhalte ich eine Nachricht des Abteilungsleiters. Er bittet mich darum, herauszufinden, warum das Projekt nach zwölf Monaten immer noch keine Ergebnisse geliefert hat. Ich soll die Resultate meiner Ermittlungen in vier Wochen auf einer bereichsübergreifenden Managementsitzung präsentieren.

Das könnte Sie auch interessieren

Der Pharmazulieferer Sartorius erlebte durch die Corona-Pandemie einen Auftrags-Boom. Deswegen musste die Organisation skaliert und neu ausgerichtet werden.

Vorschaubild

Mit agilen Metriken haben Sie verlässliche Wegweiser in Ihrem Projekt. In 7 Schritten erarbeiten Sie ein passgenaues Set von Kennzahlen und verbessern so kontinuierlich die Leistungsfähigkeit Ihres Teams.

Vorschaubild

Unerwartete Nebeneffekte können einen Produktentwicklungsprozess deutlich verzögern. Dabei ist es nachrangig, ob ein projekt- oder produktorientierter Ansatz verfolgt wird.

Man kann von Google halten was man will, aber als Ideenlieferant für die Arbeitswelt ist das Unternehmen top.

Unlocked Content

Alle Kommentare (4)

Marc
Dürr

Die "bereichsübergreifenden OKRs" sind ein extrem wichtiger Erfolgsfaktor. Ohne diese sind es nur einzelne Ziele von Personen, oder Gruppen, die ggf. sogar konträr zueinander stehen können.
Beachten sollte man dabei, dass die qualitativen Objectives der einen Gruppe IMMER auf ein quantitatives Key Result der anderen Gruppe einzahlen müssen (nicht direkt auf das qualitative Objective). Auf diese Weise erlauben OKRs ein Alignment durch die Organisation hindurch, im Idealfall für das gesamte Unternehmen.
Existieren Objectives, die auf kein Key Result einer anderen Gruppe einzahlen, dann muss man die Frage stellen, ob dieses Objective überhaupt wichtig ist, denn OKRs sind für die wichtigen Ziele gedacht - alles andere ist Business as usual und kein Führen mit Zielen.

Hallo Marc Dürr, danke für Deinen Kommentar.
Ich stimme Dir zu, dass die bereichsübergreifende Bezugnahme der OKRs ein entscheidender Faktor ist, um mit Hilfe der Methode tatsächlich ein abgestimmtes Vorgehen zu erreichen. Wichtig ist dabei auch die präzise Formulierung insbesondere der Key Results - damit die Absicht hinter dem Ziel tatsächlich erkennbar wird.
Unpräzise formulierte Ziele sind eine Gelegenheit, mangelnde Abstimmung zu kaschieren.

Freddy
Listander

Wie erwähnt wurde, sind es nicht die Tools, die den Erfolg bringen, sondern die Anwendung der Lean oder Agilen Prinzipien. Jeder im Projektmanagement kennt das Studentensyndrom (Oh, schon wieder ein OKR Quartal vorbei). Eine wöchentliche Selbstbewertung der Team OKRs, hätte wahrscheinlich mehr Transparenz in die Situation gebracht (Ähm, wir sind schon 6 Wochen in Folge ROT) und das Team zu Kurskorrekturen veranlasst.

Hallo Freddy Listander, da hast Du recht. Das ist ein guter Tipp.
Wichtig bei solchen Check-Ins (wie bei allen Routinen) ist aus meiner Erfahrung, dass sie nicht mit der Zeit zu einer Pflichtübung verkommen und nur noch der Form halber durchgeführt werden.
Ein weiterer wichtiger Aspekt ist wie der Fortschritt gemessen wird. Im von mir beschriebenen Fall wurde Fortschritt auf der technischen Seite anhand der abgearbeiteteten Arbeitspakete (in Form von Tickets) beurteilt.
Leider basierten diese Arbeitspakete zum Teil auf falschen Annahmen. Solche Probleme lassen sich durch Check-ins dann vermeiden (oder zumindest erkennen), wenn es gelingt, den Fortschritt im Hinblick auf echten Nutzen (Business Value) zu messen.
Andernfalls können Check-ins sogar zu einer trügerischen Sicherheit beitragen.