8 Tipps für ein Agiles Steuerungsmodell mit OKRs

Mittlerweile wird über Agilität genauso viel geredet, wie über das Thema Digitalisierung. Nichts ist mehr sicher vor der Agilitätswelle. Just verkündete noch ein Priester: „Wir haben unsere Kirche jetzt auch total agil aufgestellt.“ Mittlerweile gibt es keine Organisation mehr, die nicht das Label agil tragen möchte. Folglich bleibt auch keine Organisationseinheit vom obligatorischen SCRUM-Training verschont. Gespeist von diversen agilen Heilsbringern, die mit dem agilen Manifest wedeln, geht es dann um das Individuum, das Denken in konkreten Produkten, die Kollaboration mit dem Kunden und um die Veränderungsfähigkeit. Doch leider vielfach nur auf dem Papier oder in Form einer schematischen 1:1-Umsetzung der Methode. Quasi: „Methode der Methode zuliebe“. Die Fragen, die sich uns allerdings stellen, lauten: Wie lässt sich eine Organisation tatsächlich agil aufstellen? Wie lässt sich das Ambitionslevel der Einheit über das übliche Mittelmaß heben? Wie gelingt es, einen ‚Marktplatz von Opportunitäten‘ oder einen ‚optimal place to grow‘ für Talente zu schaffen? Und: macht eine 1:1-Umsetzung der Methodik überhaupt Sinn? Oder muss nicht jedes Unternehmen seinen eigenen Weg finden?

Für unser neues Team, welches sich Anfang des Jahres durch die Neugründung der Practice Company ReBuilding gefunden hat, war ausreichend Motivation vorhanden, das Thema einmal selbst anzugehen. Ziel war es, einen agilen Modus für die sukzessive Entwicklung unserer Produkte zu finden, indem wir einen schnelleren time to market realisieren.

Unser Ansatz

Wir kombinieren ein klassisches agiles Steuerungsmodell mit Objective und Key Results (OKR). Es ermöglicht uns, einen klaren Fokus zu setzen (übrigens einer unserer Werte) und auch wirklich nur jene Themen zu bearbeiten, die auf unsere übergeordneten Kollektivziele einzahlen. Es ist ein Mittel, sich Ziele (Objectives) zu setzen, die anhand von konkreten Schlüsselergebnissen (Key Results) messbar gemacht werden und bis auf die einzelnen Themen-Teams runtergebrochen werden können.

Die Vorteile einer Organisations- und Arbeitsform, die auf agilen Werten und Prinzipien basiert, lagen für uns klar auf der Hand, denn, wenn man es richtigmacht, können wir fortan

  • schneller auf Veränderungen reagieren, z.B. auf neue Kundenanforderungen
  • die Liefergeschwindigkeit von neuen Produkten und Services erhöhen
  • neben einer New Work Arbeitsumgebung, auch eine Arbeitsorganisation schaffen, die diesen Prinzipien Rechnung trägt.

Die Idee unseres Agility Teams dahinter war, das hohe Maß an Planungsvariabilität und Ambitionsniveau der OKRs mit den Vorzügen eines agilen Vorgehens zu verbinden. In der Theorie eine gute und pragmatische Idee – in der Praxis durchaus mit einigen Herausforderungen verbunden:

Ein klassisches agiles Vorgehen sowie die OKR-Logik sieht Iterationen bzw. eine Festlegung der OKRs in unterschiedlicher zeitlicher Länge vor.

Unsere Lösung: Man setzt eine Iteration für 3 Monate an, wohingegen die Community Objectives für ein Jahr gelten. Aber Vorsicht! Das impliziert, dass die übergreifenden Objectives entsprechend breit definiert sind. Ein Beispiel: „Wir sind ein High Performing Team.“

Tipp Nr. 1

Die Länge einer Iteration oder eines Sprints darf nicht mit der Gültigkeitsdauer für OKRs kollidieren.

Die Länge der Iteration entscheidet auch darüber, wie lange eine Planung von Ressourcen und Themen feststeht. In unserem Beispiel heißt das, dass wir für einen Zeitraum von 3 Monaten genau definieren, welche und wie viele Ressourcen an welchen Themen arbeiten. Kapazität für Zusatzaufgaben ist hier so gut wie nicht gegeben. Eine detaillierte Planung ist jedoch das Wichtigste in einem agilen Steuerungsmodell und damit unerlässlich! Für ein Beratungsgeschäft, in dem auch gerne mal Ad-hoc-Themen reinkommen, ist dies durchaus eine große Herausforderung.

Unsere Lösung: Die Einführung eines Teams für Ad-hoc Aufgaben. Dieses Team (oder wie wir es nennen: der Pilot mit seiner Crew) bildet sich unabhängig von den Themen-Teams für die Dauer von ca. 1 Jahr. Denn anders als in den interdisziplinären und wechselnden Themen-Teams, ist hier Beständigkeit wichtig. Gerade bei wiederkehrenden Themen braucht man Personen mit Erfahrung bei z.B. der Erstellung von Angeboten. Die Teams werden dabei von Scrum Mastern unterstützt, die wir in unserem Unternehmensbezug ‚Zeremonienmeister‘ (siehe Tipp 5) nennen.

Tipp Nr. 2

Berücksichtigen Sie Kapazitäten für die Bearbeitung von zeitkritischen und nicht planbaren Ad hoc Themen.

Ein weiterer elementarer Bestandteil unserer Kombination aus agilem Vorgehen und OKRs sind die Communites of Practice (CoP). Sie waren zunächst nicht viel mehr als ein Überbleibsel unserer Altstruktur, aber dennoch nicht wegzudenken. Denn die Communities of Practice sind unsere Wissensträger: z.B. Design Thinking, Agile Organisation, Business Ecosystems, Customer Excellence, Future Communications, New Work, Future Trends. Sie tragen eine besondere Aufgabe. Und die Herausforderung war es, diese Altstruktur in die neue Logik zu überführen, denn ihre initiale Aufgabe hat sich nun grundlegend verändert. Sie suchen sich ihre Themen nicht mehr selbst und erarbeiten in ihrem Silo neue Konzepte. Sie bringen von nun an ihr Wissen aktiv in interdisziplinäre Teams ein. Ihre Hauptaufgabe besteht also fortan darin, ihr Wissen zu teilen und natürlich weiterzuentwickeln sowie als Themenexperten bereit zu stehen. Sie treffen sich immer noch regelmäßig zum Wissensaustausch, doch gearbeitet wird in interdisziplinären Teams! Dass dies für einige Mitarbeiter eine große Veränderung war, kann man sich vorstellen.

Unsere Lösung: Wir erklären, warum wir uns neu organisieren und Themen lieber interdisziplinär statt in Silos lösen wollen. Ist der Verständnis-Funke einmal übergesprungen, war der Rest der Community wie von selbst Feuer und Flamme für das neue Modell.

Tipp Nr. 3

Haben Sie gute Gründe für Ihr Handeln und legen Sie diese plausibel dar.

Das Wort Planung hat, wie die meisten ‚agilen‘ Leser sicher wissen, eine besondere Bedeutung im Rahmen agiler Steuerungsmodelle. Der Kern der Planung ist nämlich das Backlog oder Themenspeicher, wie wir ihn ‚old fashioned‘ nennen. In ihm sind alle wichtigen Aktivitäten einer Iteration aufgenommen. Dabei folgen die Themen aber keiner Hierarchie. Sie können sowohl von COPs, einzelnen Community-Mitgliedern, dem Practice Council (was das nun wieder ist, dazu kommen wir später) oder auch top-down abgeleitet aus der Unternehmensstrategie einfließen. An sich ein einfaches Prinzip, doch das muss erstmal kommuniziert werden! Wenn die Practice gerade erst neu gebildet wurde und die Mitglieder nicht zeitgleich dazu stoßen und entsprechend nicht die gleichen Wissensstände haben, ist dies eine Herausforderung.

Unsere Lösung: Regelmäßige Kommunikation. Wir führten von Anfang an diverse Kommunikationsformate ein, sei es ein großes Summit zum Auftakt jeder Iteration, ein regelmäßiger Newsletter oder das 2-wöchentliche Bi-Weekly. Die Informationen müssen ja irgendwie an die Frau bzw. den Mann kommen! Zur Reflexion trifft sich das Gremium in regelmäßigen Abständen zu Retroperspektiven. Mit der Reflexion wird eine iterative Verbesserung der Zusammenarbeit angestrebt.

Tipp Nr. 4

Erstellen Sie von Anfang an eine Kommunikationsstrategie. Man kann in Veränderungsprozessen nicht genug kommunizieren.

Der Themenspeicher ist das eine, doch viel wichtiger ist dessen Priorisierung. Aus einem übergreifenden Themenspeicher muss nämlich für jede Iteration aufs Neue ein Iterations-Themenspeicher gemacht werden. Um diese Aufgabe zu erledigen, gibt es den Practice Council. Ein Mix aus erfahrenen Mitarbeiterinnen und Mitarbeitern jeder Karrierestufe. Aber bevor wir uns diesen und weiteren Rollen widmen, die bei dem aufgebauten Konstrukt so langsam notwendig werden, noch kurz etwas zur Priorisierung von Themen – ein schwieriges Unterfangen, man möchte doch am liebsten alles gleichzeitig umgesetzt wissen.

Unsere Lösung: Wir haben unsere agilen Coaches mit an den Tisch geholt. Eine stringente Moderation und Fokussierung auf das Ergebnis war Gold wert inmitten lebhafter Diskussionen rund um die Wichtigkeit und Dringlichkeit einzelner Themen.

Tipp Nr. 5

Lassen Sie insbesondere zu Beginn das Planning von erfahrenen agilen Coaches moderieren.

Dass unser entwickeltes Steuerungsmodell nicht von selbst läuft, wurde uns relativ schnell klar. Aus diesem Grund haben wir neben dem bereits beschriebenen Piloten mit seiner Crew folgende Rollen eingeführt: Product Owner, Zeremonienmeister und das Practice Council. Der Product Owner ist neben der initialen Anforderungsbeschreibung und der Definition von Akzeptanzkriterien am Ende der Iteration für die Qualität der Ergebnisse verantwortlich und nimmt diese daher ab. Zuvor unterstützt und challenged er kontinuierlich das heterogene Team seines Themas, das sich interdisziplinär aus den unterschiedlichen CoPs zusammensetzt.

Darüber hinaus haben wir die Rolle des Zeremonienmeisters eingeführt der für die operative Exzellenz des Steuerungsmodells und dessen Umsetzung verantwortlich ist. Die inhaltliche Steuerung und Gesamtverantwortung für die Practice wurde vom sogenannten Practice Council übernommen. Wichtig war uns dabei, auf Begriffe wie ‘Leadership‘ oder ‚Management‘ zu verzichten, da wir ein möglichst nicht hierarchisches und dem agilen Modell folgendes Vorgehen abbilden wollten. Das initiale Practice Council bildeten dabei acht Personen unterschiedlicher Karrierestufen und Hintergründe. Ein Novum für unsere Organisation - und auch hier hat die Erfahrung aus der ersten Iteration uns einiges gelehrt in Hinsicht auf die ideale Arbeitsgröße eines Steuerungsteams.

Unsere Lösung: Die gibt es noch nicht. Wir sind noch kein Jahr alt und müssen diesbezüglich noch etwas herumexperimentieren. Wir versuchen gerade den Ansatz, dass das Practice Council nur noch aus 4 Mitgliedern besteht, um insbesondere Diskussionen abzukürzen und schneller Entscheidungen herbeizuführen. Und zusätzlich haben wir ein Sounding Board eingeführt, dem die ehemaligen Practice Council Mitglieder nun zugehörig sind. Eine Person des Sounding Boards wird gezielt je nach Fachexpertise zu Practice Council Terminen eingeladen, um einen anderen Blickwinkel mit hinein zu tragen und in Vertretung für das Sounding Board an Entscheidungen mitzuwirken.

Tipp Nr. 6

Verschiedene Rollen und Verantwortlichkeiten sind ein Muss für agile Steuerungsmodelle. Jedoch kopieren Sie nicht eins zu eins die Rollen wie sie im Lehrbuch stehen, adaptieren Sie sie an die besonderen Gegebenheiten in Ihrem Organisationsumfeld.

Nachdem die Pfeiler des agilen Steuerungsmodells sowie die notwendigen Rollen feststanden, stellte sich die Frage nach dem Modus Operandi. Es steht nun der Prozess, die Planungszyklen sowie Meetingstruktur (Planning, Bi-Weekly, Demo, Retro), doch eins ist noch offen: das Tool!

In diesem sollten insbesondere die Themen und OKRs sauber abgebildet werden können. Die Entscheidung, welches Tool es werden würde, fiel uns relativ leicht. Unser San Francisco Office empfahl uns unseren Kooperationspartner Workboard. Denn das Tool ist nicht nur super benutzerfreundlich, sondern digitalisiert die essentiellen Komponenten des Modells: OKRs und Kanban Board je Themen-Team. Die Anschaffung eines komplett neuen Tools und das damit verbundene Durchlaufen der Konzern-IT und Sicherheitsprozesse stellte sich allerdings als ein sehr langwieriges und aufwändiges Unterfangen heraus, sodass wir das Tool erst viel später als geplant einführen konnten.

Unsere Lösung: Option 1 (Idealfall): Bevor sie in die erste Iteration starten, stellen Sie sicher, dass das Tool startklar ist sowie das agile Vorgehensmodell klar durchdacht und kommuniziert ist. Option 2: Wenn das Tool nicht zu Beginn der ersten Iteration fertig ist, dann warten sie mit der Einführung bis zur 2. Iteration. Vermeiden Sie es, während den Iterationen neue Tools und Prozessschritte einzuführen. Das überfordert die Mitarbeiter und ist nicht effektiv.

Tipp Nr. 7

Wählen Sie nur eine der oben genannten beiden Optionen und vermeiden Sie tunlichst die Mischform.

Tipp Nr. 8

Entscheiden Sie sich für ein Tool, welches Ihre Bedürfnisse optimal abbildet und den Prozess einfach digitalisiert und somit für alle transparent macht.

 

Nicht alles auf einmal bitte. Setzen Sie auf eine Einführung in kleinen Schritten, die für alle Mitarbeiter gut nachvollziehbar sind. 

 

Weitere Lektüre:

Marc Wagner zum agilen Steuerungsmodell mit OKRs auf LinkedIn

Marc Wagner zum Company-Rebuilding-Ansatz im Interview mit Gunnar Sohn:
https://youtu.be/EjMlR0db6nU