In Kürze: Der Widerspruch agilen Wandels
Viele Firmen versuchen, agile Methoden wie Scrum einzuführen, schaffen es aber nicht, wirklich etwas zu verändern. Das Problem ist, dass sie nur taktische Prozesse umsetzen, ohne ihre grundlegende Struktur, Kultur und Führungsstil anzupassen.
Echte Agilität erfordert hingegen tiefgreifende systemische Veränderungen in der Organisationsstruktur, der Führung und den technischen Praktiken, nicht nur die Ausführung von Ritualen. Ohne diesen grundlegenden Wandel vom „doing Agile” zum „being Agile” kommen Transformationen zum Stillstand und die versprochenen Vorteile bleiben zwangsläufig aus.
Das grundlegende Problem mit dem agilen Wandel
Zwei Jahrzehnte nach dem Agile Manifesto sind wir in einer rätselhaften Situation. Agile Praktiken, vor allem Scrum, haben sich in vielen Branchen durchgesetzt. Trotzdem berichten viele Unternehmen von großen Herausforderungen, wie stockenden Transformationen, dem Rückzug von Teams und ausbleibenden versprochenen Vorteilen. Studien zeigen, dass ein beträchtlicher Prozentsatz der Agile-Initiativen die Erwartungen nicht erfüllt.
Die Probleme deuten auf einen grundlegenden Widerspruch hin: Unternehmen setzen Agile taktisch ein, während sie versuchen, strategisch inkompatible Systeme beizubehalten. Dieser Ansatz ist nicht nur eine Herausforderung bei der Umsetzung, sondern stellt einen grundlegenden Fehler im Verständnis dessen dar, was Agile eigentlich ist. Untersuchungen zeigen, dass Unternehmen Agile häufig taktisch auf Team- oder Prozessebene implementieren, ohne ihre bestehenden Kommando- und Kontrollstrukturen und Managementparadigmen grundlegend zu überdenken oder abzubauen.
Die fünf Irrtümer bei der Einführung von Agile
1. Der Fehler bei der Definition: „Agile anwenden” statt Arbeitsweise umgestalten
Die meisten Unternehmen sehen Agile als Ersatz für einen Prozess, tauschen Wasserfall-Artefakte gegen Scrum-Events aus und erwarten, dass in der Hälfte der Zeit doppelt so viel Arbeit erledigt wird. Teams haben jetzt Daily Scrums statt Statusmeetings, Produkt-Backlogs statt Anforderungsdokumente und Sprint Reviews statt Meilensteinpräsentationen. Diese oberflächliche Einführung schafft die Illusion einer Transformation, während die zugrunde liegende Koordinationslogik erhalten bleibt.
Die Realität: Bei Scrum geht es nicht in erster Linie um Events oder Artefakte. Es geht darum, die Art und Weise, wie Arbeit entdeckt, priorisiert und validiert wird, grundlegend umzugestalten. Wenn Unternehmen Scrum „installieren”, ohne die Art und Weise zu ändern, wie Entscheidungen getroffen werden, wie Feedback fließt oder wie Lernen stattfindet, verweigern sie sich selbst die Kernvorteile. Das Ergebnis ist das, was wir als „Agile Theatre” oder „Cargo Cult Agile” bezeichnen können, also im Wesentlichen Agilität zur Schau stellen, ohne dass Substanz dahintersteckt.
2. System über Aufgabe: Lokale Optimierung vs. organisatorische Adaption
Unternehmen optimieren oft die Praktiken auf Teamebene: Sie verbessern die Velocity, optimieren das Backlog-Management und führen effiziente Events durch. Allerdings scheuen sie sich oft davor, die organisatorischen Systeme anzugehen, die Übergaben erzwingen, Abhängigkeiten schaffen, jährliche Budgetzyklen vorschreiben oder Initiativen mit festem Umfang aufrechterhalten.
Die Realität: Ein leistungsstarkes Scrum-Team, das in eine traditionelle Organisationsstruktur eingebettet ist, stößt fast sofort an seine Grenzen. Die agilen Prinzipien, auf Veränderungen zu reagieren und somit kontinuierlich Wert zu liefern, kollidieren mit vierteljährlichen Planungszyklen, Abteilungs-Silos, dem durch Anreize geförderten Drang zur lokalen Optimierung und mehrstufigen Genehmigungsprozessen.
Diese Spannung zeigt sich ganz konkret: Produktverantwortliche, denen es in der Regel an echter Eigenverantwortung und Entscheidungsbefugnis mangelt, agieren lediglich als Backlog-Verwalter oder Anforderungserfasser und nicht als Wertmaximierer. Darüber hinaus werden Teams durch externe Abhängigkeiten blockiert, und eine starre Governance hemmt Innovationen. Mit anderen Worten: Traditionelle Governance-Strukturen, die durch starre Stage-Gates, umfangreiche Dokumentationsanforderungen und zentralisierte Genehmigungsprozesse gekennzeichnet sind, werden wahrscheinlich Agiles Bedarf an Geschwindigkeit, Flexibilität und minimaler Dokumentation kollidieren.
Das Kernproblem liegt in der Komplexität. Moderne Unternehmensumgebungen, die zunehmend von Volatilität, Unsicherheit, Komplexität und Ambiguität (VUCA) geprägt sind, erfordern adaptive Ansätze, um die Strategie an die Realität anzupassen oder zu vermeiden, dass alles auf eine Karte gesetzt wird. Dennoch arbeiten viele Unternehmen nach wie vor mit Strukturen, die für stabilere, berechenbarere und kontrollierbare Umgebungen konzipiert wurden, was zu einer grundlegenden Diskrepanz zwischen Problemfeld und Lösungsansatz führt.
3. Die Illusion der Entfaltung: „Selbstorganisierende“ Teams in entmächtigenden Systemen
Das vielleicht heimtückischste Muster ist der Widerspruch zwischen der erklärten Empowerment innerhalb kontrollierender Systeme. Teams wird gesagt, sie seien selbstorganisiert und befähigt, Entscheidungen zu treffen, doch wichtige Entscheidungen über Roadmaps, Personalausstattung, Architektur und Prioritäten werden in der Regel an anderer Stelle getroffen. Dieser Widerspruch untergräbt langsam aber sicher die gesamte Idee der Agilität, da das Management das eine sagt, während das Organisationssystem etwas anderes durchsetzt.
Die Realität: Echte Befähigung erfordert strukturelle Veränderungen. Entscheidungsbefugnisse müssen klar delegiert und unterstützt werden: Die Leute, die am nächsten am Problem dran sind, sollten die meisten Entscheidungen treffen. Stattdessen haben Teams oft keine echte Autorität über ihre Arbeit, einschließlich Umfang, Zeitplan oder Prozess, und Entscheidungen bleiben zentralisiert und werden von oben nach unten getroffen. Wenn Unternehmen behaupten, autonome Teams zu wollen, aber gleichzeitig Kommando- und Kontrollstrukturen beibehalten, schaffen sie Zynismus und Desinteresse.
Außerdem scheint mangelnde Unterstützung durch das Management einer der Hauptgründe für das Scheitern von Agile zu sein. Oft geht es dabei nicht nur um fehlende verbale Ermutigung, sondern darum, dass die Führung agile Prinzipien nicht versteht, Command-and-Control-Gewohnheiten nichta aufgibt oder die notwendigen strukturellen Veränderungen nicht vornimmt, um die Voraussetzungen für erfolgreiche Team-Autonomie zu schaffen.
4. Technische Exzellenz und der Widerspruch agilen Wandels: Die fehlende Grundlage
Viele Transformationen konzentrieren sich nur auf Prozessänderungen und vergessen dabei die technischen Praktiken, die nachhaltige Agilität ermöglichen. Teams übernehmen zwar Iterationen und User Stories, lassen aber Praktiken wie Testautomatisierung, kontinuierliche Integration und Refactoring links liegen.
Die Realität: Dieses Muster der Prozessübernahme ohne technische Praktiken ist ein Hauptgrund für gescheiterte agile Initiativen. Nachhaltige Agilität basiert auf starken technischen Grundlagen. Ohne Praktiken wie automatisierte Tests und kontinuierliche Integration sammeln Teams technische Schulden an, die letztendlich ihre Fähigkeit beeinträchtigen, schnell und zuverlässig Wert zu liefern. Stattdessen erfordert erfolgreiche Agilität die Übereinstimmung zwischen den agilen Praktiken auf Teamebene und dem gesamten „Betriebssystem“ der Organisation, einschließlich der technischen Praktiken.
5. Der Irrtum des Betriebssystems: Scrum als Plugin
Im Kern ist Scrum ein ganz anderes Betriebsmodell, das für komplexe, unvorhersehbare Umgebungen entwickelt wurde, in denen Adaption und Lernen wichtiger sind als Vorhersagen und Kontrolle. Trotzdem behandeln viele Unternehmen es wie ein Plugin für ihr bestehendes organisatorisches Betriebssystem mit Befehls- und Kontrollhierarchien.
Die Realität: Dieser Kategorienfehler, ein adaptives Framework auf einem Betriebssystem für Vorhersagen laufen zu lassen, führt zu unüberbrückbaren Konflikten. Diese entstehen aus grundlegend unterschiedlichen philosophischen Grundlagen. Traditionelle Managementstrukturen basieren auf dem wissenschaftlichen Management (Taylorismus), das von Frederick Winslow Taylor im frühen 20. Jahrhundert entwickelt wurde und Effizienz, Standardisierung und Kontrolle in den Vordergrund stellt. Im Gegensatz dazu basiert Agilität auf den Prinzipien der Adaption, Zusammenarbeit und verteilten Entscheidungsfindung. Während der Taylorismus von ganz anderen Annahmen ausgeht, betrachtet er Arbeit als zerlegbar in einfache, standardisierte und wiederholbare Aufgaben. Er geht davon aus, dass es für jede Aufgabe eine einzige, effizienteste Methode gibt, was der allgemeinen Erfahrung in komplexen Umgebungen widerspricht, in denen wir bereits Schwierigkeiten haben, die notwendigen Arbeiten zu identifizieren.
Wenn diese beiden Systeme aufeinanderprallen, dominiert daher in der Regel die traditionelle Struktur, was zu Kompromisslösungen führt, die zwar die äußere Form von Agile beibehalten, aber nicht dessen Wesen.
Widerspruch agilen Wandels: Auf dem Weg zu echter Veränderung
Wie können Unternehmen aus diesem Dilemma rauskommen? Es gibt mehrere Wege:
1. Strukturelle Neuausrichtung
Anstatt Agilität einfach in bestehende Strukturen zu packen, richten erfolgreiche Unternehmen ihre Strukturen an Wertströmen aus. Um über die Optimierung einzelner Teamprozesse hinauszukommen, muss das gesamte Betriebsmodell überdacht werden. Dieser wichtige Schritt umfasst:
- Umstellung von funktionalen Abteilungen auf funktionsübergreifende Produktteams.
- Reduzierung von Organisationsebenen und Genehmigungsinstanzen.
- Bildung von festen Teams anstelle von projektbezogener Personalbesetzung.
- Ausrichtung der Supportfunktionen (Personalwesen, Finanzen usw.) an agilen Prinzipien.
2. Veränderung der Führung
Führungskräfte müssen mehr als nur unterstützen, sie müssen Agile auch leben, indem sie eine doppelte Rolle übernehmen: Sie müssen die agile Initiative aktiv fördern und gleichzeitig ihren eigenen Führungsstil ändern, zum Beispiel durch:
- Wechsel von einem direktiven zu einem dienenden Führungsstil.
- Klare Visionen und Grenzen statt detaillierter Anweisungen.
- Vorleben einer Lernmentalität, die Experimentierfreudigkeit und Adaption verinnerlicht.
- Schaffung einer psychologischen Sicherheit für Teams, damit sie Probleme ansprechen, Risiken eingehen und dabei auch Fehler machen dürfen.
Führung ist also ausgesprochen wichtig für jede Organisation, die „agil” werden will. Aber leider untergräbt die Führung oft ihre eigene Rolle, weil es an Verständnis, Unterstützung, aktiver Beteiligung und Engagement fehlt; alles wichtige Faktoren, die zum Scheitern führen können.
3. Systemische Änderungen an den unterstützenden Funktionen
Eine echte Veränderung braucht ein neues Denken über die Kernfunktionen der Organisation. Wenn diese Funktionen in alten, nicht agilen Paradigmen stecken bleiben, kann das zu Problemen führen. Deshalb machen erfolgreiche Unternehmen Änderungen wie:
- Wechsel von projektbasierter Finanzierung zu dauerhaften Produktteams mit ergebnisorientierten Kennzahlen.
- Wechsel von einer jährlichen Budgetierung zu flexibleren, inkrementellen Finanzierungsmodellen, die auf die iterative, adaptive Natur von Agile abgestimmt sind.
- Weiterentwicklung der Personalpraktiken vom individuellen Leistungsmanagement zum Aufbau von Teamfähigkeiten, wobei Praktiken wie jährliche individuelle Leistungsbeurteilungen, Ranglistensysteme und Belohnungsstrukturen, die auf das Erreichen persönlicher Ziele ausgerichtet sind, überwunden werden.
- Neugestaltung der Governance, um den Fokus auf Ergebnisse statt auf die Einhaltung von Plänen zu legen.
4. Technische Exzellenz und Handwerkskunst
Unternehmen müssen ebenso in technische Fähigkeiten investieren. Um wirklich agil zu sein, braucht es Geld für technische Schulungen, Mentoring und DevOps-Infrastruktur und -Praktiken. Deshalb konzentrieren sich erfolgreiche Engineering-Unternehmen auf:
- Technische Agilität durch Praktiken wie Testautomatisierung, kontinuierliche Bereitstellung und sauberen Code aufzubauen.
- Eine Kultur der Handwerkskunst zu schaffen, in der Qualität nicht verhandelbar ist.
- Teams Zeit zu geben, technische Schulden abzubauen und ihre Tools und Praktiken regelmäßig zu verbessern.
- Nicht nur die Velocity, sondern auch Nachhaltigkeit und Qualität zu messen.
Das Fazit zum Widerspruch agilen Wandels: Von der Einführung zur Transformation
Der Widerspruch agilen Wandels bleibt bestehen, weil es einfacher ist, Prozesse zu ändern als Paradigmen. Die Einführung von Scrum-Events erfordert lediglich Schulungen und Anpassungen des Zeitplans. Die Transformation einer Organisation erfordert hingegen, grundlegende Annahmen über Kontrolle, Hierarchie und Wertschöpfung zu hinterfragen.
Bei einer echten agilen Transformation geht es nicht darum, Scrum zu praktizieren, sondern darum, eine Organisation zu werden, die in komplexen Umgebungen kontinuierlich lernen, sich anpassen und Wert liefern kann. Dieser Ansatz erfordert nicht nur neue Praktiken, sondern auch neue Denkmodelle.
Unternehmen, die das Paradoxon überwinden, erkennen, dass Agilität nicht etwas ist, das man „macht”, sondern etwas, das man verkörpert. Die Entscheidung, vor der Unternehmen stehen, ist nicht, ob sie Agile gut oder schlecht umsetzen. Es geht darum, ob sie wirklich agil werden wollen. Der eigentliche Fehler liegt nicht in Agile selbst, sondern in der grundlegenden Diskrepanz zwischen der Einführung adaptiver Praktiken und dem Festhalten an veralteten Managementparadigmen. Solange Unternehmen diesen systemischen Konflikt nicht lösen, bleibt das Versprechen echter Agilität ein Wunschtraum.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 40.000 Abonnenten anschließen.