OKR Podcast #36: Testgetriebenes Management mit OKR

Inspiriert durch den Vortrag von Allan Kelly auf dem OKR Focus Day der Mayflower GmbH, habe ich mir Gedanken zu einer technischen Betrachtung des Frameworks Objectives & Key Results (OKR) gemacht. Als ich noch stark in der Software-Entwicklung unterwegs war, habe ich mich gefragt, ob die Prinzipien von testgetriebener Entwicklung und verhaltensorientiertem Design (BDD) sich auch auf das Management übertragen ließe? Damals war ich im mittleren Management und war es einfach leid, wenn “Entscheidungen” getroffen wurden, deren Grundlage oder Auswirkung mir einfach nicht verständlich waren. Dieser Blogbeitrag basiert auch auf einer Präsentation, die ich vor einiger Zeit auf der Iterate.Ruhr gehalten habe¹.

Extreme Programming zur Rettung

Anfang 2000 übernahm ich die Entwicklungsleitung für ein großes Softwareprojekt. Dieses Projekt war schon zum Zeitpunkt meiner Übernahme seit mehreren Jahren überfällig. Die verbliebenden Interessenten wurden durch Exkursionen und Veranstaltungen bei Laune gehalten. Der reale Entwicklungsstand glich eher einer Großbaustelle. Die Entwickler hatten völlig inkompatible Module entwickelt und versuchten diese “händisch” zu integrieren. Die aufgrund einer externen Beratung genutzte technische Basis, damals der heiße Scheiß, war wackelig und fehleranfällig ². Kaum etwas funktionierte. Glücklicherweise gab es zwei Ereignisse, die eine positive Wendung für unser Team brachten.

Zunächst fiel mir das Buch “Extreme Programming Explained” von Kent Beck in die Hände. In dem Buch beschrieb Kent Beck die Entwicklung komplexer Software anhand der Metapher einer Reise. Bei einer größeren Reise ist das Ziel zwar bekannt, aber der Weg kann durch unvorhergesehene Ereignisse sehr unterschiedlich ausfallen. Mir wurde das später selbst schmerzlich bewusst, als ich bei einer Autofahrt zum Comer See auf die Idee kam, statt den Tunnel über den Bergpaß zu fahren.

Komplexe Arbeit bedeutet, das Ziel im Auge zu halten, aber in der täglichen Arbeit auf die unerwarteten Dinge immer wieder zu reagieren. Der Fahrer oder die Fahrerin des Autos passen sich auch kontinuierlich an die Verkehrssituation an: von der Stauumgehung bis hin zur Straßensperre. Mir gingen einige Lichter auf. Software-Entwicklung hat mehr mit Reagieren auf unvorhergesehene Ereignisse als mit Planung und Architektur zu tun.

Testgetriebene Entwicklung (TDD)

Ein weiteres durch Extreme Programming eingeführtes Konzept waren die Unit-Test (Modultests). Die Unit-Tests in Kombination mit einer kontinuierlichen Integration waren für unser damaliges Softwareprojekt die Rettung. Ohne Unit-Tests wären wir gescheitert. Unit-Testing bedeutet, dass im Code ein erwartetes Verhalten vor der eigentlichen Entwicklung als Test beschrieben wird. Erst dann wird der Nutzcode programmiert. Eine Ampel zeigt an, ob das gewünschte Verhalten erreicht ist oder nicht. Grün bedeutet, die Fahrt kann weitergehen. Wie im Straßenverkehr.

Dieses Konzept wird als Test Driven Development (TDD) bezeichnet und Kent Beck gebührt der große Verdienst, diese verloren gegangene “Kulturtechnik”³ wieder populär gemacht zu haben.

Akzeptanztests für fachliche Anforderungen (BDD)

Eine Verlagerung der “testgetriebenen” Entwicklung auf eine höhere Ebene waren die Akzeptanztests. Hier hat sich aus meiner Sicht der Wiki-Erfinder Ward Cunningham sehr hervorgetan². Akzeptanztests formulieren, wie eine fachliche Idee oder eine User Story auf erfolgreiche Umsetzung geprüft werden kann. Akzeptanztests haben die wunderbare Eigenschaft, dass zu einer vagen fachlichen Idee jetzt mess- und prüfbare Kriterien gefunden werden müssen.

Ich erinnere mich noch gut: Viele Fachleute taten sich damals sehr schwer, mit dieser Idee. Sie waren es gewohnt, eine Lösung vorzugeben, statt das Ergebnis einer Lösung zu beschreiben. Es zeigte sich dann, dass die Idee der Akzeptanztests den Lösungsraum viel größer aufspannte und gleichzeitig die Arbeit schneller fertig wurde.

Während also die Unit-Tests die technische Ebene testen, bewegen wir uns mit den Akzeptanztests auf der fachlichen Ebene. Aber wie sieht es mit der strategischen Ebene aus?

Testgetriebene Business-Hypothesen (OKR)

Auch das Framework Objectives & Key Results hat sich weiterentwickelt. Der Erfinder von OKR, der ehemalige Intel Chef Andy Grove, wollte mit OKRs seine Mitarbeiter ins Handeln bringen. Die Idee war, dass das Objective das Ziel beschreibt und die Key Results die vielen kleinen Haltestellen zum Ziel⁴. Natürlich bedeutet die Metapher der “Haltestelle”, dass die Key Results damals in der Regel Meilensteine waren, die konkrete Zwischenergebnisse beschrieben.

Modernes OKR hat einen weitergehenden Anspruch an die Zielbildung. Gute OKRs beschreiben Outcomes. Ein Outcome ist im weitesten Sinne eine Business-Hypothese mit einem klaren Nutzen für Menschen, idealerweise dem Kunden oder Nutzer. In diesem Szenario beschreibt das Objective das gewünschte Outcome oder eine Business-Hypothese und die Key Results sind der Akzeptanztest der Hypothese. Und da wären wir schon, beim testgetriebenen Management. Stellt euch vor, dass jede Hypothese oder jede Entscheidung klare Erfüllungskriterien hätten. Wie toll wäre das denn?

Damit wären wir auf der strategischen Ebene angekommen:

• Unit-Tests beschreiben technische Ergebnisse.
• Akzeptanztests beschreiben fachliche Ergebnisse.
• OKRs beschreiben Business-Hypothesen und die Kriterien, an denen die Hypothesen validiert werden können.

Und damit beschreiben OKRs den Missing Link zwischen der Produktstrategie und der Produktentwicklung über User Stories. OKRs sind testgetriebene Hypothesen für Kundennutzen.

OKRs als API eines Teams

Allan Kelly hat in seinem Vortrag auf dem OKR Focus Day eine weitere “nerdige” Analogie aufgezeigt, die mir sehr gefiel. Wenn Teams selbst und eigenständig OKRs für sich definieren, dann beschreiben die Teams die Erwartungen, die an diese für das nächste Quartal gestellt werden können. Oder anders gesagt, sie eröffnen mit den OKRs einen Freiraum für eigenständiges Handeln. Sie spannen einen Raum auf, in dem nicht mehr hereingeredet wird? Klingt das nicht gut? Das ist auch gut.

Diese OKRs sind eine Art API (Schnittstelle) für die Kommunikation mit anderen Teams. Jedes Team hat eine selbstbestimmte Erwartungshaltung. Jeder weiß, wo er dran ist. Da wären wir fast schon beim objektorientierten Management, aber vielleicht ist das dem Guten zu viel.

Zusammenfassung

Ich gebe zu. Alle Analogien und Beispiele in diesem Text interessieren eventuell hart gesottene Software-Entwickler. Menschen, die Probleme lösen wollen und Klarheit erwarten. Da ich selbst ein Entwickler war, bewegt diese Betrachtung von OKRs auch etwas bei mir.

OKRs sind ein Medium der Kommunikation und der Soziologe Niklas Luhmann sagte, dass jedes Medium die Kommunikation zwar limitiert, aber genau durch diese Limitierung unendlich viele Formen von Kommunikation hervorbringen kann⁵.

Und daher freue ich mich auf die Vielfalt der OKRs, die sich aus einer TDD bzw. API-Metapher heraus bilden werden.