Die agile Bewegung hatte mit ihrer Diagnose recht. Organisationen, die in einer unvorhersehbaren Umwelt mit Plänen, Freigaben und Abteilungsgrenzen arbeiten, verlieren gegen solche, die in kurzen Zyklen lernen und nah an der Sache entscheiden. Dass viele agile Transformationen trotzdem nach zwei, drei Jahren stehen bleiben, widerlegt diese Diagnose nicht. Es zeigt, dass sie auf der falschen Ebene umgesetzt wurde.
Agilität hatte recht, nur nicht auf der Ebene, auf der sie eingeführt wurde
Das Agile Manifest von 2001 ist kein Methodenhandbuch. Es ist ein Plädoyer dafür, Entscheidungen dorthin zu geben, wo das Wissen liegt, und Pläne als Hypothesen zu behandeln. Eines seiner zwölf Prinzipien sagt, dass die besten Architekturen, Anforderungen und Entwürfe aus selbstorganisierten Teams entstehen. Das ist im Kern eine Aussage über Entscheidungsarchitektur, nicht über Rituale.
In den Organisationen kam diese Idee meist als Methode an: als Scrum-Einführung, als Trainingsprogramm, als neues Rollenmodell. Methoden lassen sich ausrollen, messen und abhaken. Entscheidungsrechte, Budgetregeln und das Selbstverständnis der Führung lassen sich nicht ausrollen. Sie müssen entschieden werden. Craig Larman hat das in seinen „Gesetzen des organisationalen Verhaltens“ zugespitzt: Organisationen sind unausgesprochen darauf optimiert, bestehende Positionen und Machtstrukturen nicht zu verändern, und jede Veränderungsinitiative wird so lange umgedeutet, bis die neuen Begriffe im Wesentlichen den alten Zustand beschreiben.
Das erklärt ein vertrautes Bild. Aus dem Abteilungsleiter wird der Chapter Lead, aus dem Projekt das Epic, aus dem Lenkungskreis das Portfolio-Board. Die Begriffe sind neu, die Entscheidungswege die alten. Für diese Form ohne Wirkung hat sich der Begriff Cargo-Kult eingebürgert.
Drei Ebenen agiler Transformation
Agile Transformation verläuft in der Praxis auf drei Ebenen. Jede verändert etwas anderes, und jede braucht eine andere Art von Entscheidung. Die meisten Transformationen sind auf der ersten Ebene erfolgreich, auf der zweiten mühsam und erreichen die dritte nie.
| Ebene und was sich ändert | Wer entscheidet, und wo es typischerweise hakt |
|---|---|
| Team: Arbeitsweise, Takt, Rollen im Team (Scrum, Kanban) | Team und Bereichsleitung. Hakt, sobald das Team auf Entscheidungen außerhalb seiner Reichweite wartet. |
| Zusammenarbeit vieler Teams: gemeinsame Planung, Abhängigkeiten (SAFe, LeSS, Nexus) | Bereichs- und Portfolioverantwortliche. Hakt an Prioritäten, die nicht geklärt sind, und an Strukturen, die quer zum Kundenproblem liegen. |
| Unternehmen: Entscheidungsrechte, Budgetlogik, Strategie, Arbeitsweise der Führung | Nur die Geschäftsführung. Hakt, weil diese Entscheidungen selten ausdrücklich gestellt werden. |
Der Übergang von der zweiten zur dritten Ebene ist der Punkt, an dem eine agile Transformation zur Organisationsfrage wird. Hier geht es nicht mehr darum, wie Teams arbeiten, sondern darum, wer worüber entscheidet, wie Geld fließt und woran Erfolg gemessen wird. Diese Fragen liegen auf dem Tisch der Geschäftsführung, und dort bleiben sie oft liegen.
Fünf Muster, an denen agile Transformationen stecken bleiben
In meiner Arbeit mit Führungsteams kehren fünf Muster immer wieder. Sie sind keine Fehler einzelner Personen, sondern Mechanismen, die aus der Struktur entstehen. Ausführlich beschrieben sind sie in der Reihe zu den zwölf Blockademustern.
Entscheidungsrechte bleiben oben. Verantwortung wurde delegiert, die Rechte, die dazu gehören, nicht. Teams könnten schneller sein, warten aber auf Freigaben, die woanders erteilt werden. Kontrolle erzeugt Zurückhaltung, Zurückhaltung rechtfertigt die Kontrolle. Das ist das Führungsvakuum.
Agilität kommt obendrauf. Die neuen Formate laufen zusätzlich zu den alten Gremien und Berichten. Nichts wird beendet, die Kapazität verteilt sich auf immer mehr. Das ist strukturelle Überlastung.
Das Neue wird mit den Maßstäben des Alten gemessen. Experimente müssen sich im Jahresbudget und im Business Case beweisen, bevor sie etwas lernen konnten. Wer Experimente wie Projekte genehmigt, bekommt Projekte. Das ist die Innovationsblockade.
Teams optimieren für sich. Jedes Team wird schneller, das Kundenproblem liegt zwischen den Teams und bleibt liegen. Melvin Conway hat schon 1968 beschrieben, dass Organisationen Lösungen bauen, die ihre eigene Kommunikationsstruktur abbilden. Wer die Teams neu schneidet, ohne die Verantwortung für das Kundenproblem neu zu regeln, verschiebt die Grenze nur. Das ist Team-Isolation.
Die Organisation hat gelernt abzuwarten. Nach mehreren Programmen, die ohne erklärten Abschluss versandet sind, gilt auch das agile als vorübergehend. Abwarten ist dann keine Verweigerung, sondern eine vernünftige Antwort auf Erfahrung. Das ist Change-Fatigue.
Eine agile Transformation ist erst dann eine Transformation, wenn sich verändert, wie oben entschieden wird.
Was Skalierungs-Frameworks leisten und was nicht
Wenn die Teams an ihre Grenzen stoßen, liegt der Schritt zu einem Skalierungs-Framework nahe. SAFe, LeSS, Nexus oder das Spotify-Modell ordnen die Zusammenarbeit vieler Teams, schaffen gemeinsame Takte und geben Rollen für die Abstimmung. Das ist nützlich, wenn viele Teams an einem Produkt arbeiten und sich gegenseitig blockieren.
Die Entscheidungen der dritten Ebene ersetzt ein Framework nicht. Es beschreibt, wie Teams zusammenarbeiten, wenn Prioritäten, Budgets und Entscheidungsrechte geklärt sind. Sind sie es nicht, kommt mit dem Framework eine weitere Schicht an Rollen, Terminen und Gremien hinzu, und die offene Frage wandert in eine neue Struktur. Bezeichnend ist das Spotify-Modell: Es wurde weltweit kopiert, und ehemalige Spotify-Mitarbeitende haben später beschrieben, dass es selbst dort nie so vollständig gelebt wurde, wie die vielzitierten Grafiken nahelegen. Kopiert wurde die Form, nicht die Entscheidungen dahinter.
Ein Framework beantwortet deshalb die Frage, wie viele Teams zusammenarbeiten. Die vorgelagerte Frage, wer worüber entscheidet und woran sich Erfolg bemisst, beantwortet die Führung.
Wann Agilität passt und wann nicht
Agilität ist keine Eigenschaft, die eine Organisation überall gleich braucht. Gerhard Wohland unterscheidet zwei Arten von Problemen. Blaue Probleme wiederholen sich und lassen sich mit Wissen lösen: Planung, Standards, Effizienz. Rote Probleme sind neu und überraschend. Sie brauchen Urteil, kurze Wege und Menschen, die nah an der Sache entscheiden dürfen. Das Cynefin-Modell von Dave Snowden trifft eine ähnliche Unterscheidung zwischen komplizierten Problemen, die sich analysieren lassen, und komplexen, die sich nur durch Versuch und Beobachtung erschließen.
Agile Arbeitsweisen sind eine Antwort auf rote, komplexe Probleme. Wer sie auch dort einführt, wo die Arbeit blau ist, erzeugt Aufwand ohne Nutzen. Wer sie dort verweigert, wo die Arbeit rot ist, bleibt zu langsam. Die meisten Organisationen haben beides, oft im selben Bereich. Die Frage ist deshalb nicht, ob ein Unternehmen agil wird, sondern wo und in welcher Form.
| Agilität als Rollout | Agilität als Entscheidung |
|---|---|
| Alle Bereiche arbeiten künftig agil | Agil arbeiten die Bereiche mit neuen, unsicheren Problemen |
| Erfolg heißt: Methoden eingeführt | Erfolg heißt: Entscheidungen fallen schneller und näher am Kunden |
| Teams werden geschult | Entscheidungsrechte und Budgetlogik ändern sich mit |
| Führung sponsert das Programm | Führung ändert, wie sie selbst entscheidet |
| Ein Framework für alle | Je Bereich die Form, die zum Problem passt |
Ob und wo Agilität passt, lässt sich prüfen, bevor ein Programm startet. Der Agile Suitability Canvas zeigt je Bereich, wie neu und unsicher die Arbeit ist und welche Form von Steuerung zu ihr passt.
Die vier Entscheidungen der Geschäftsführung
Wenn eine agile Transformation feststeckt, liegt die Ursache selten bei den Teams. Sie liegt in einer kleinen Zahl von Entscheidungen, die nur die Geschäftsführung treffen kann. Vier tauchen in fast jedem Fall auf.
Wer worüber entscheidet. Welche Entscheidungen Teams treffen dürfen, ohne sie nach oben zu geben, und welche bei der Führung bleiben. Solange das nicht ausdrücklich geregelt ist, wandern Entscheidungen im Zweifel nach oben. Eine schriftliche Klärung für die häufigsten Entscheidungstypen bewirkt oft mehr als ein weiteres Training.
Wie Geld fließt. Ein Jahresbudget mit festen Projekten passt nicht zu Arbeit, die in kurzen Zyklen lernt. Die Beyond-Budgeting-Bewegung um Jeremy Hope und Robin Fraser hat schon Anfang der 2000er Jahre gezeigt, dass starre Budgetzyklen Anpassung systematisch bremsen. Budgets in Tranchen, freigegeben nach Evidenz statt nach Jahresplan, passen zu agiler Arbeit.
Was dafür wegfällt. Agilität braucht Kapazität. Ohne die Entscheidung, welche Vorhaben enden, verteilt sich die neue Arbeitsweise auf eine Organisation, die schon voll ist. Die wirksamste Regel ist oft die einfachste: keine neue Initiative ohne eine, die endet.
Wie die Führung selbst arbeitet. Wenn der Führungskreis weiter über Statusberichte und Meilensteine steuert, während die Teams in Sprints lernen, sendet die Organisation zwei widersprüchliche Signale. Menschen folgen verlässlich dem, was die Führung tut. Ein Führungskreis, der seine eigenen Prioritäten in kurzen Zyklen überprüft und Entscheidungen als Hypothesen mit Prüftermin trifft, verändert die Organisation stärker als jedes Programm.
Diese vier Entscheidungen bilden zusammen die Entscheidungsarchitektur einer Organisation: wer entscheidet, auf welcher Grundlage und was danach verbindlich gilt. Eine agile Transformation, die diese Architektur nicht anfasst, verändert die Oberfläche.
Ein Vorgehen in drei Schritten
Wer erkannt hat, dass die Transformation an Entscheidungen hängt, steht vor der nächsten Falle: alle vier auf einmal angehen zu wollen. Daraus wird schnell das nächste Programm, mit Programmbüro, Arbeitspaketen und Statusberichten. Wirksamer ist ein Vorgehen, das bei der einen Entscheidung ansetzt, die gerade am meisten bewegt. Nicht die einzige, sondern die, nach der die anderen leichter fallen.
Entdecken. Das Führungsteam sammelt Beobachtungen aus sechs Perspektiven: das Problem der Kunden, die Organisation, die Teams, die Führung, die Art, wie Neues entsteht, und die Strategie. Ziel ist nicht eine Maßnahmenliste, sondern das Muster, das die Transformation aufhält. Der Transformation Discovery Compass ist für diesen Schritt gebaut.
Entscheiden. Aus dem Muster folgt eine Entscheidungsfrage, die das Führungsteam mit einer Festlegung beantworten kann, etwa welches Geschäft eine eigene Erfolgslogik mit Budget in Tranchen bekommt oder welche Entscheidungen die Teams ab dem nächsten Quartal selbst treffen. Die Entscheidung wird als Hypothese getroffen, mit Prüftermin.
Verankern. Was trägt, geht in die Struktur: in Budgets, Rollen, Gremien und Berichte. Erst dann ist es keine Initiative mehr, sondern die neue Regel. Danach beginnt der nächste Durchgang mit der nächsten Entscheidung.
Zwei veröffentlichte Fälle zeigen, wie unterschiedlich der Einstieg aussehen kann. In einem Industriekonzern, der organisatorisch mit seinem Wachstum nicht Schritt hielt, war der erste Schritt nicht die Wahl eines Frameworks, sondern ein gemeinsames Zielbild der Top-Führung, aus dem eine Transformationslogik und erste Pilotprojekte folgten (Fall ansehen). In einem Pharmaunternehmen, in dem Scrum, OKR und Design Thinking eingeführt, aber jeweils anders verstanden wurden, stand am Anfang ein gemeinsames Verständnis, was Agilität dort leisten soll (Fall ansehen).
Die agile Bewegung hat gezeigt, wie Teams arbeiten, die schnell lernen. Ob eine Organisation so arbeiten kann, entscheidet sich nicht in den Teams. Es entscheidet sich an der Stelle, an der die Führung bereit ist, ihre eigenen Entscheidungen anders zu treffen.
