3 Modelle für die vernachlässigte Koordinationsebene zwischen strategischem Management und operativen Teams

Während der Mittagspause eines unserer ScrumMaster-Trainings schütteten mir die Leiterin der HR-Abteilung und ein erfahrener ScrumMaster ihre Herzen aus. Ihr Unternehmen sollte zur agilen Organisation werden, aber sie wussten nicht recht weiter: „Bei uns fehlt die Koordinationsebene. Wir haben auf der einen Seite agile Teams, die an Projekten und Produkten arbeiten. Auf der anderen Seite steht die Geschäftsleitung, die Kontrolle, Zugriff und Verantwortliche will, um effizient durchregieren zu können. Der Austausch zwischen Teamebene und strategischer Leitungsebene findet nur vereinzelt statt, es wird zu wenig kommuniziert.“

Diese Situation hat zur Folge, dass sich die agil arbeitenden Teams alleingelassen fühlen. Die ScrumMaster fangen an, Scrum intern als Methode zu verteidigen, weil das Warum dahinter aus dem Blick geraten ist. Sie stoßen täglich auf Impediments, die außerhalb des Teams liegen, doch im Unternehmen findet sich kein tragfähiges Modell, um teamübergreifende Impediments systematisch zu lösen. Es macht sich bei der Geschäftsleitung der Eindruck breit, dass „agil“ nicht so richtig funktioniert und der Ruf nach mehr disziplinarischer Führung wird laut. Letztlich stockt die so optimistisch begonnene agile Transition des Unternehmens.

Was ist los?

Es fehlt eine Koordinationsebene zwischen dem Oben und Unten, zwischen Strategie und Umsetzung, zwischen Unternehmenszielen und Teamzielen, zwischen Führungsmethoden und Produktentwicklungsmethoden.

Wenn agile Methoden in einem Unternehmen eingeführt werden, dann sieht das häufig so aus: Scrum, Kanban und Co. werden anstelle des klassischen Projektmanagements eingeführt und eingesetzt. Das geschieht auf Projektteam- bzw. Produktteamebene. Die Geschäftsleitung betrachtet diese Teams als ungefährliche Spielwiese für agiles Arbeiten. Und das war’s dann. Die wenigsten Unternehmen verzahnen von Anfang an die operative Teamebene systematisch mit der strategischen Leitungsebene.

Und immer wieder stelle ich fest, dass agile Methoden und Konzepte für die Organisationsebene den verantwortlichen Führungskräften schlicht und einfach nicht bekannt sind. Unternehmensagilität scheitert also auch am fehlenden Methodenwissen.

Drei Modelle für eine bessere Koordination

Es gibt eine Vielzahl an etablierten Methoden bzw. Modellen, um Agilität auf Unternehmensebene umzusetzen und dadurch das Oben und Unten zu koordinieren. In diesem Blog möchte ich kurz und knapp und ohne Anspruch auf Vollständigkeit drei wichtige Methoden bzw. Modelle vorstellen.

1. Objectives and Key Results, kurz OKRs, wie Google und Co. sie einsetzen:

Bei OKRs handelt es sich um ein Zielmanagementkonzept, mit dem alle Ebenen eines Unternehmens aufeinander abgestimmt und gemeinsam ausgerichtet werden. Ausgehend von der Unternehmensvision werden Jahresziele oder Moals, und daraus Company OKRs abgeleitet, möglicherweise gibt es auf Bereichsebene Bereichs-OKRs. Auf der Teamebene werden Team-OKRs entwickelt, die auf die Bereichs- bzw. Company-OKRs einzahlen. Dabei gibt es Impulse sowohl von oben als auch von unten, die in einem Kommunikationsprozess aufeinander abgestimmt werden. OKR arbeitet mit OKR-Zyklen, die man sich wie große Sprints auf Unternehmensebene vorstellen kann. Ein OKR-Zyklus dauert in der Regel drei oder vier Monate. So ist sichergestellt, dass mehrmals pro Jahr auf allen Ebenen des Unternehmens geprüft und korrigiert wird, ob der Kurs noch stimmt. Starre Jahresplanungen gehören der Vergangenheit an. Während des geschützten Raums eines OKR-Zyklus wird gearbeitet, ohne dass von oben oder von der Seite hineinregiert wird. Schließlich wird mit OKR-Reviews und OKR-Retros auf den Arbeitserfolg geschaut und Verbesserungen werden umgesetzt.

2. Kanban Flight Levels, wie sie von Klaus Leopold entwickelt wurden:

Warum Kanban nur auf Teamebene machen? Immer da, wo optimiert werden muss, immer da, wo zu viel Arbeit ins System gekippt wird, hilft es, mittels Visualisierung den Arbeitsfluss zu erkennen und diesen zu optimieren. Auf Flight Level 3, der Ebene des strategischen Portfoliomanagements und der Vorstandsentscheidungen besteht in vielen Unternehmen die Gefahr, dass zu viel gleichzeitig angestoßen wird. Das mittlere Flight Level 2 sorgt dafür, dass „oben“ die Folgen von Entscheidungen unmittelbar gespürt werden und gleichzeitig die Teamebene „unten“ – dank der Koordinationsebene – Gehör bei „denen“ da oben findet. Hier werden die Interaktionen zwischen Teams und Abteilungen über den gesamten Prozess koordiniert, end-to-end von der Idee bis zur Wirkung. Und schließlich gibt es mit Flight Level 1 die operative Ebene, die Teamebene.

Kurz zusammengefasst: Auf Strategieebene gibt es ein Kanban-Board mit den Initiativen, Fokusthemen und Jahreszielen. Auf den Teamebenen gibt es Boards mit der operativen Arbeit und dazwischen gibt es Boards mit Koordinationsthemen.

3. Das Transition-Team im Zusammenspiel mit den ScrumMaster-Teams:

Scrum-Teams werden zum zahnlosen Tiger, wenn es keine starken ScrumMaster oder Agile Coaches gibt, die Impediments auf die Leitungsebenen hochspielen und dort lösen lassen. Transitions-Initiativen stocken, wenn Impediments nicht von oben angegangen werden. Mit dem Konzept des Transition-Teams wird von Anfang an sichergestellt, dass die agilen Pilotteams nicht alleine gelassen werden und der Wandel vom Top-Management aktiv mitgestaltet wird. Das Transition-Team ist mit echten Treibern der Transformation zur agilen Organisation besetzt und besteht aus Mitgliedern der Geschäftsleitung bzw. des Vorstandes sowie Vertretern der Scrum-Teams und weiteren Schlüsselrollen. Es arbeitet selbst nach Scrum und entwickelt somit iterativ und inkrementell das Unternehmen weiter. Wichtigster Partner des Transition-Teams ist das ScrumMaster-Team. Im Zusammenspiel wird sowohl die strategische als auch die operative Ebene der Transformation umgesetzt.

 

Die oben vorgestellten Konzepte können separat oder in beliebiger Kombination in einem Unternehmen zum Einsatz kommen. Doch Vorsicht: Auch diese Konzepte sind kein Erfolgsgarant für Business-Agilität. Der Wandel im Unternehmen kann damit genauso scheitern wie bei der Einführung von Scrum oder Kanban auf Teamebene. Diese Konzepte funktionieren nur dann, wenn das Top-Management von Anfang an integraler Bestandteil der Transition ist und die neue Koordinationskultur vorlebt. Nur dann können die neuen Vorgehensweisen Altes ersetzen. Nur dann verändern sich Unternehmenskultur, Führungsverhalten und Business-Agilität.

Was wünsche ich mir?

Ich wünsche mir eine größere Bekanntheit dieser Methoden und Konzepte für Agilität auf Unternehmensebene. Ich wünsche mir, dass künftig in Trainings und Workshops über Business-Agilität geredet wird. Dann werden die vielen agilen Transformationsvorhaben zu echten Erfolgsstorys.

Und eins darf niemals vergessen werden: Agilität und agile Methoden sind kein Selbstzweck. Es geht um Nutzerorientierung. Es geht um Prozessoptimierung und dabei um Qualität und um Geschwindigkeit. Geschwindigkeit von der Idee bis zur Wirkung, bei der Gewinnung von Feedback vom Markt und beim Lernen.

In diesem Sinne: Lassen Sie uns im Gespräch bleiben zum Thema Business-Agilität.

 

Foto von Aurélien Lemasson-Théobald auf Unsplash

Geschrieben von

Arved Weidemüller Arved Weidemüller

Mit Scrum fand Arved Weidemüller einen Rahmen für das, was ihm in Projekten wichtig ist: ein menschliches Miteinander, Kommunikation und eine klare, kundenorientierte Vision. Ein deutlich definiertes „Warum?“ bringt aus seiner Sicht mehr Erfolg als die reflexartige Frage nach Terminen und Kosten. Als Champion für OKR (Objectives & Key Results) berät er Großkonzerne und Mittelständler. Durch seine umfangreiche Erfahrung im Baumanagement – er ist Architekt, zertifizierter Projektsteuerer und Mitglied im German Lean Construction Institute – findet Arved leicht den Draht zu Menschen auf allen Hierarchiestufen. Er sieht seine Aufgabe darin, einen gemeinsamen Willen zu schaffen, mit dem echte Veränderung möglich wird. Im Zusammenhang mit Digitalisierungsprojekten und Building Information Modeling begann er bereits 2015, agile Arbeitsweisen in der Bauprojektplanung einzusetzen und bringt als agiler Berater bei borisgloger consulting sowohl Bau- als auch Softwareentwicklungsprojekte voran.

TEILE DIESEN BEITRAG

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email