Agile Transformation: 66 Prozent melden Erfolg, 53 Prozent haben ihn

Das Pilotteam funktioniert fast immer. Acht bis zehn Leute, ein klares Produkt, ein motivierter Product Owner, viel Aufmerksamkeit von oben. Nach zwei Quartalen liefert es schneller als der Rest der Organisation, und die Präsentation im Lenkungskreis ist ein Selbstläufer.

Der Bruch kommt danach. Sobald aus einem Team zwanzig werden, treffen agile Arbeitsweisen auf Jahresbudgets, Ressourcenpools, Abteilungsgrenzen und Führungskräfte, deren Statusdefinition an der Zahl ihrer Direct Reports hängt. Genau hier entscheidet sich, ob eine agile Transformation stattfindet oder ob eine Organisation nur ein paar agile Inseln bekommt.

Die Zahlen dazu sind unangenehm präzise.

Passend zum Thema

Kulturwandel statt Scheinerfolg

Wenn agile Methoden zwar eingeführt, im Arbeitsalltag jedoch an verkrusteten Denkmustern und informellen Machtstrukturen scheitern, entsteht die typische Lücke zwischen deklariertem und echtem Transformationserfolg. Nur wenn sich Haltung und Zusammenarbeit parallel zu den Prozessen wandeln, tragen neue Arbeitsweisen nachhaltig Früchte. Im Seminar Change Management und Unternehmenskultur analysieren Sie die tiefer liegenden Mechanismen gewachsener Organisationskulturen und deren Einfluss auf Veränderungsvorhaben. Sie erlernen fundierte Diagnoseverfahren zur Kulturanalyse, identifizieren verdeckte Blockaden und erarbeiten zielgerichtete Interventionsstrategien für Teams und Führungsebenen. Zudem trainieren Sie, wie Sie ein tragfähiges Zielbild für gemeinsame Werte definieren und psychologische Sicherheit im Arbeitsalltag verankern. Damit schaffen Sie das fundamentale Fundament, auf dem echte organisationale Agilität dauerhaft gelingt.

Seminar: Change Management und Unternehmenskultur

Was die Studien wirklich sagen

Die Boston Consulting Group hat 127 Unternehmen weltweit zu ihren Agilitätsinitiativen befragt. Fast alle — 94 Prozent — hatten agile Initiativen gestartet, und zwei Drittel bezeichneten ihre agile Transformation als erfolgreich. Fragte man aber nach, welche agilen Praktiken tatsächlich angewendet wurden und welche Ergebnisse erreicht waren, sagten nur rund 53 Prozent, dass sie ihre Transformationsziele erreicht und einen dauerhaften Wandel in Kultur, Arbeitsweise und Zusammenarbeit geschaffen hatten. Von den Unternehmen, die sich selbst eine hohe agile Reife bescheinigen, hat nur etwa die Hälfte ihre Ziele wirklich erreicht und kann geschäftliche Wirkung nachweisen.

Die Lücke zwischen 66 und 53 Prozent ist die eigentliche Nachricht. Ein Sechstel der Unternehmen hält die eigene Transformation für gelungen, obwohl die Belege fehlen — und merkt es nicht, weil niemand die richtigen Kennzahlen erhebt.

Zur berühmten Zahl, mit der fast jede Präsentation zu diesem Thema beginnt, lohnt eine Einordnung. Die Behauptung, 70 Prozent aller Transformationen scheiterten, lässt sich in dieser Form kaum belegen. Eine Recherche, die der Zahl nachgegangen ist, fand keine glaubwürdige Studie, die 70 Prozent als gemessene Scheiterquote unter einer einheitlichen Definition ausweist. BCG veröffentlichte 2020 zwar eine 70 im Zusammenhang mit digitaler Transformation, doch die Aufschlüsselung relativiert sie: 30 Prozent waren vollständig erfolgreich, 44 Prozent schufen Wert, verfehlten aber ihre Ziele, und 26 Prozent erreichten wenig oder nichts.

Für die Praxis heißt das: Nicht „scheitern“ ist der Normalfall, sondern „liefert etwas, aber nicht das Versprochene“. Das ist ein anderes Problem und verlangt eine andere Antwort.

Der Sprung vom Pilotteam in die Organisation

Ein Pilotteam braucht Methodenwissen. Eine skalierte Organisation braucht veränderte Strukturen. Das ist der Unterschied, den die meisten Transformationsprogramme unterschätzen.

Vier Dinge ändern sich beim Übergang grundlegend:

Abhängigkeiten werden zum dominierenden Problem. Ein Team kann sich selbst organisieren. Zwanzig Teams, die an einem Produkt arbeiten, verbringen den größten Teil ihrer Zeit mit Warten aufeinander. Skalierung ist im Kern kein Methodenthema, sondern die Frage, wie man Arbeit so schneidet, dass möglichst wenige Übergaben nötig sind.

Rollen werden knapp. Für jedes skalierte Team braucht es einen Product Owner und einen Scrum Master — qualifizierte Kapazitäten, die gerade zu Beginn einer umfassenden Agilisierung rar sind. Hinzu kommt, dass die Vollzeitmitarbeit in einem agilen Team eine echte Herausforderung darstellt, weil viele Beschäftigte parallel in mehreren Projekten stecken.

Die Governance passt nicht mehr. Jahresbudgets, Projektfreigaben und Meilensteinberichte setzen voraus, dass man zu Jahresbeginn weiß, was im dritten Quartal richtig ist. Wer die Steuerungslogik unverändert lässt, bekommt Teams, die zweimal planen: einmal für das Portfolio-Gremium und einmal für sich.

Die Führungsstruktur steht plötzlich im Weg. Darauf ist der übernächste Abschnitt gerichtet.

Passend zum Thema

Agile Methoden wirksam verankern

Echter Nutzen entsteht in Transformationsprojekten nicht durch das bloße Übernehmen neuer Begrifflichkeiten, sondern durch das fehlerfreie Beherrschen und konsequente Ausrichten an inkrementellen Lieferergebnissen. Wer agile Werkzeuge rein mechanisch abarbeitet, verfehlt die erhoffte Flexibilität und Geschwindigkeit. Im Seminar Agiles Projektmanagement – Teil I steigen Sie tief in die operative Mechanik agiler Vorgehensweisen und Prinzipien ein. Sie erarbeiten die Kernkomponenten von Kanban und Scrum, trainieren die präzise Formulierung von User Stories und moderieren strukturierte Retrospektiven sowie Planungsrituale. Darüber hinaus lernen Sie, den Wertzuwachs von Arbeitspaketen kontinuierlich transparent zu machen und Priorisierungsentscheidungen nach messbarem Kundennutzen zu treffen. So verwandeln Sie theoretische Methodenkompetenz in nachweisbaren, wirtschaftlichen Projekterfolg.

Seminar: Agiles Projektmanagement – Teil I

Skalierungsframeworks im Vergleich

Es gibt kein Framework, das eine Organisation transformiert. Es gibt Frameworks, die unterschiedliche Wetten eingehen.

Framework	Grundidee	Stärke	Risiko
SAFe	mehrschichtiges Modell mit Agile Release Trains, eigenen Rollen auf Programmebene	anschlussfähig an bestehende Konzernstrukturen	erzeugt viel Prozess; Rollen heißen wie in Scrum, bedeuten aber anderes
LeSS	Scrum radikal auf mehrere Teams ausgedehnt, möglichst wenige Zusatzrollen	zwingt zu echter Strukturveränderung	verlangt hohe Bereitschaft, Hierarchie abzubauen
Nexus	Scrum-Erweiterung für drei bis neun Teams an einem Produkt	schlank, nah am Scrum Guide	deckt Portfolioebene nicht ab
Scrum@Scale	modularer Baukasten, skaliert einzelne Elemente	anpassbar, wenig Vorgabe	wenig Führung durch das Framework selbst
Spotify-Modell	Squads, Tribes, Chapters, Guilds	eingängig, kulturell attraktiv	war nie ein Framework, sondern eine Momentaufnahme
Disciplined Agile	Entscheidungsbaukasten statt fester Vorgaben	kontextsensitiv	hoher Einarbeitungsaufwand

Diese Frameworks bieten Orientierung, ersetzen aber weder klare Ziele noch konsequente Führung, und jedes bringt eigene Chancen und Risiken mit. Die praktisch wichtigere Frage kommt vor der Frameworkwahl: Wie man Produkte zuschneidet und ob man überhaupt skaliert, ist vermutlich bedeutsamer als die Entscheidung, welches Skalierungsframework man wählt.

Ein häufiger Fallstrick bei SAFe verdient eine eigene Warnung. Der Product Owner in SAFe ist nicht dasselbe wie der Product Owner in Scrum — er verfeinert meist das Backlog auf Teamebene, während die inhaltliche Verantwortung beim Produktmanagement auf Ebene des Agile Release Train liegt. Wer das nicht explizit macht, produziert Rollenkonflikte, die niemand benennen kann, weil beide Seiten dieselben Wörter benutzen.

Das mittlere Management als Engpass

Die Führungsebene, die Transformationen entscheidet, ist nicht die, die sie trägt. Vorstände beschließen, Teams arbeiten, und dazwischen steht eine Gruppe, deren Rolle niemand neu definiert hat.

Das mittlere Management erlebt agile Skalierung häufig als Bedrohung, weil die klassische Steuerungslogik infrage gestellt wird. Gleichzeitig braucht die Organisation genau diese Gruppe: Sie übersetzt Strategie in konkrete Prioritäten, entfernt Hindernisse, die Teams nicht selbst lösen können, und moderiert Spannungen zwischen Linienlogik, Produktlogik und Regulierung.

Das erklärt, warum das Abschaffen dieser Ebene regelmäßig nach hinten losgeht. Die Mehrheit der Unternehmen ist weiterhin hierarchisch aufgestellt, während agile Methoden und Anforderungen auf die Teams einprasseln. Genau dieser Zwitterzustand ist das Problem: Agile Teams treffen auf hierarchische Grundstrukturen, die mit den neuen Freiheiten nicht umgehen können — und die Vermittlung zwischen diesen Welten landet beim mittleren Management.

Der Ausweg ist ein Rollenwechsel mit anderem Statusversprechen. Statt die Ebene abzuschaffen, werden Rollen neu definiert: vom Controller zum Enabler, vom Gatekeeper zum Brückenbauer, vom Mikromanager zum Coach für Wirksamkeit.

Damit das trägt, muss der Statusverlust materiell kompensiert werden. Wenn Gehaltsband, Titel und Beförderungslogik weiterhin an der Zahl der Unterstellten hängen, ist jede Rollenbeschreibung Papier. Wer mittlere Führungskräfte in Enabler-Rollen bringen will, muss die Vergütungssystematik anfassen — und das ist ein HR-Projekt, kein Agile-Projekt.

Eine Zahl, die in der Beratungsliteratur kursiert, beschreibt die Lage auf der Ebene darüber: 62 Prozent des Topmanagements sollen der Ansicht sein, Agilität habe für sie selbst keine Konsequenzen. Die Quelle dafür ist nicht eindeutig belegt, das Muster aber bekannt: Führung delegiert die Transformation nach unten und behält die eigene Steuerungslogik bei.

Passend zum Thema

Transformationen iterativ steuern

Lineare Projektpläne greifen zu kurz, wenn komplexe Transformationsprozesse selbst agil gesteuert und kontinuierlich an unvorhersehbare Rahmenbedingungen angepasst werden müssen. Fehlen transparente Feedbackschleifen für den Gesamtprozess, verpuffen Veränderungsinitiativen nach anfänglicher Euphorie. Im Seminar Agiles Change Management übertragen Sie agile Steuerungslogiken direkt auf die Begleitung organisatorischer Transformationen. Sie lernen, Veränderungsprozesse in handhabbare Iterationen zu zerlegen, Change-Backlogs zu pflegen und Akzeptanzmessungen über kurze Feedbackzyklen direkt in die nächste Prozessphase einzuspeisen. Zudem üben Sie den gezielten Einsatz von Co-Creation-Formaten, um Mitarbeitende aktiv einzubinden und Widerstände faktenbasiert aufzufangen. Dadurch sichern Sie eine adaptive Transformationssteuerung, die messbare Ergebnisse liefert und den Wandel Schritt für Schritt absichert.

Seminar: Agiles Change Management

Warum Velocity als Steuerungsgröße schadet

Velocity misst, wie viele Story Points ein Team pro Sprint abschließt. Als Planungshilfe innerhalb eines Teams ist das nützlich. Als Kennzahl für die Transformation ist es schädlich, aus drei Gründen.

Sie ist teamintern und nicht vergleichbar — Story Points sind eine relative Schätzeinheit ohne Bezug zwischen Teams. Sie ist manipulierbar: Steigende Velocity lässt sich durch großzügigeres Schätzen erzeugen, ohne dass mehr geliefert wird. Und sie misst Output, nicht Wirkung. Velocity ist eine interne Output-Kennzahl für den Durchsatz eines Teams — sie misst weder Kundennutzen noch Qualität noch Produkterfolg.

Der Kern des Problems: Mehr Stunden zu arbeiten und mehr Features zu liefern führt nicht zwangsläufig zu besseren Kundenerfahrungen. Wer Velocity zur Steuerungsgröße macht, bekommt genau das — mehr Features, keine bessere Wirkung.

Belastbar wird die Messung erst auf drei Ebenen, die sich ergänzen.

Lieferfähigkeit messen: die DORA-Metriken

Die vier klassischen DORA-Metriken — Deployment Frequency, Lead Time for Changes, Change Failure Rate und Time to Restore Service — geben einen ausgewogenen Blick auf Durchsatz und Stabilität und machen Engpässe im Fluss ebenso sichtbar wie Lücken in der Widerstandsfähigkeit.

2021 ergänzte das DORA-Team eine fünfte Metrik, Reliability, die die Gesamtgesundheit des Systems abbildet, einschließlich Verfügbarkeit, Latenz und Fehlerraten. In der aktuellen DORA-Fassung gehört die Rework Rate in das Kernmodell aus fünf Metriken statt nur als ergänzende Größe.

Zwei Anwendungsregeln sind entscheidend. Die Kennzahlen sind auf Anwendungs- oder Serviceebene am aussagekräftigsten; das Zusammenfassen ungleicher Systeme verdeckt reale Engpässe. Und: Verschlechtern sich die Werte, sind sie als Daten über das System und seine Engpässe zu lesen, nicht als Beleg für „Minderleistung“ von Personen.

Der zweite Punkt ist der, an dem Transformationen scheitern. Sobald DORA-Werte in Zielvereinbarungen auftauchen, werden sie optimiert statt genutzt.

Wertfluss messen: Flow-Metriken

DORA misst, was das Lieferteam produziert. Es misst nicht, ob die richtigen Dinge durch die Organisation fließen.

Mik Kersten, CTO von Planview, entwickelte das Flow Framework, um diese Lücke zu schließen und Softwareorganisationen eine Möglichkeit zu geben, die Lieferung von Geschäftswert über den gesamten Wertstrom zu messen und zu optimieren — mit dem Bild, dass die Messung nur eines Bereichs im Wertstrom sei, als nutze man von einem Zwölf-Zoll-Lineal nur zwei Zoll. Die Flow-Metriken sollen die DORA-Metriken nicht ersetzen, sondern ergänzen.

Flow Time misst, wie lange die Fertigstellung eines Arbeitselements dauert, inklusive Wartezeit. Flow Load zeigt, ob ein Team überlastet ist. Beide ergänzen DORA um Sichtbarkeit für Prozessreibung und das Gesamttempo der Lieferung.

Für skalierte Organisationen ist Flow Efficiency — der Anteil aktiver Bearbeitung an der gesamten Durchlaufzeit — die aufschlussreichste Größe. Werte im niedrigen einstelligen Prozentbereich sind keine Seltenheit. Sie bedeuten, dass Arbeit über 90 Prozent der Zeit liegt und wartet. Kein Methodentraining der Welt verbessert das; nur der Abbau von Abhängigkeiten tut es.

Wirkung messen: Evidence-Based Management

Die dritte Ebene fragt, ob das Gelieferte etwas bewirkt hat. Evidence-Based Management arbeitet dafür mit vier Key Value Areas: Unrealized Value als Blick auf die Ziele der Organisation, Current Value als Zustand relativ zu diesen Zielen, Time-to-Market als Reaktionsfähigkeit und Ability-to-Innovate als Wirksamkeit beim Liefern von Wert.

Die marktbezogenen Bereiche — Unrealized Value und Current Value — bilden Kundenergebnisse ab, während die Bereiche zur Organisationsfähigkeit — Ability-to-Innovate und Time-to-Market — die Fähigkeit beschreiben, wertvolle Kundenergebnisse überhaupt liefern zu können. Das Framework hält ausdrücklich fest, dass Input-, Aktivitäts-, Output- und Wirkungsmaße einer Organisation nichts über ihre Fähigkeit sagen, wertvolle Ergebnisse zu liefern.

Geschäftswert zu liefern ist wichtig, aber Organisationen müssen zugleich zeigen, dass sie auf Veränderung reagieren können und Innovationsfähigkeit über die Zeit erhalten — sonst droht Stagnation.

Praktisch heißt das: drei bis fünf Kennzahlen pro Ebene, nicht dreißig. Ein Dashboard mit dreißig Metriken wird nicht gelesen, sondern verwaltet.

Typische Rückfallmuster erkennen

Transformationen brechen selten ab. Sie erodieren, und zwar in erkennbaren Mustern. Wer sie früh benennt, kann gegensteuern.

• Agiles Theater. Die Zeremonien laufen weiter, die Entscheidungen fallen wieder in der Linie. Erkennbar daran, dass Retrospektiven keine Maßnahmen mehr erzeugen oder dieselben Maßnahmen quartalsweise wiederkehren.
• Rollen ohne Mandat. Es gibt Product Owner, aber Prioritäten kommen aus dem Lenkungskreis. Erkennbar daran, dass das Backlog nach Sitzungen umsortiert wird.
• Agile Inseln. Zwei Bereiche arbeiten agil, der Rest nicht, und die Schnittstellen fressen den Gewinn auf. Erkennbar an steigender Flow Time bei gleichbleibender Velocity.
• Rückfall unter Druck. Bei Terminnot wird das Vorgehen ausgesetzt, „nur diesmal“. Wenn das zweimal passiert, ist es die neue Normalität.
• Kennzahlen als Zielvorgabe. Sobald DORA-Werte oder Velocity in Boni einfließen, werden sie unbrauchbar.
• Coach-Abhängigkeit. Nach dem Abzug externer Coaches fällt die Organisation binnen eines Quartals zurück. Der Test dafür ist einfach: Was passiert, wenn man den Coach vier Wochen abzieht?

Was die Transformation kostet und wie lange sie dauert

Verlässliche Durchschnittswerte gibt es nicht, weil Umfang und Ausgangslage zu stark variieren. Die Kostenblöcke sind aber immer dieselben: externe Beratung und Coaching, Ausbildung und Zertifizierung, produktive Zeit für Trainings und Neuaufstellung, häufig Tooling für Backlogs und Wertstromtransparenz, und in vielen Fällen Abfindungen oder Umbesetzungen im Führungsbereich.

Der größte, selten budgetierte Posten ist der Produktivitätseinbruch in der Umstellungsphase. Teams, die neu zusammengesetzt werden, liefern zunächst weniger.

Zur Dauer gibt es einen belastbaren Erfahrungswert: In größeren Unternehmen zieht sich eine agile Transformation über mehrere Jahre, bis das veränderte Selbstverständnis in allen Bereichen angekommen ist — und die Pflege der Kultur endet danach nicht. Wer eine Transformation als Projekt mit Enddatum aufsetzt, hat den Charakter der Sache missverstanden.

Wann agile Transformation nicht sinnvoll ist

Nicht jede Organisation braucht sie, und nicht jeder Bereich. Der ehrliche Abgleich spart erhebliche Kosten.

Gegen eine breite Transformation sprechen: stabile Anforderungen mit langen Planungshorizonten, stark regulierte Abläufe mit Nachweispflichten, Bereiche ohne echten Kundenkontakt und Wertströme, in denen der Engpass nicht in der Koordination liegt, sondern in Kapazität oder Technik.

Auch die Unternehmensgröße spielt eine Rolle. Junge Unternehmen sind oft ohnehin flexibel und dezentral — bei ihnen geht es eher darum, zunächst Stabilität und Struktur zu schaffen, weil Agilität eine Balance zwischen Alignment und Autonomie verlangt.

Der beste Ausgangspunkt ist deshalb nicht die Frage „Wie werden wir agil?“, sondern „Wo genau kostet uns mangelnde Anpassungsfähigkeit Geld?“. Wenn sich diese Frage nicht mit einem konkreten Wertstrom beantworten lässt, ist der Zeitpunkt für eine Transformation nicht gekommen.

Häufige Fragen

Was ist eine agile Transformation?

Eine agile Transformation ist die Umstellung einer Organisation auf Strukturen, Steuerungslogik und Kultur, die schnelle Anpassung ermöglichen. Sie betrifft Struktur, Strategie, Belegschaft, Prozesse und Technologie und ist ausdrücklich mehr als die Einführung agiler Softwareentwicklung auf Unternehmensebene. Die Einführung von Scrum in einzelnen Teams ist noch keine Transformation, sondern eine Methodenänderung.

Wie viele agile Transformationen scheitern?

Eine seriöse Einzelzahl gibt es nicht. Belastbar ist die BCG-Erhebung unter 127 Unternehmen, nach der zwei Drittel ihre Transformation für erfolgreich hielten, aber nur gut die Hälfte die Ziele tatsächlich erreicht und dauerhaften Wandel geschaffen hatte. Die oft zitierte Quote von 70 Prozent lässt sich unter einer einheitlichen Definition nicht belegen.

Woran scheitern agile Transformationen am häufigsten?

An unveränderter Governance und an der Führungsebene, nicht an den Teams. Konkret: Jahresbudgets und Projektfreigaben bleiben bestehen, während Teams iterativ arbeiten sollen; das mittlere Management bekommt keine neue Rollendefinition; und Erfolg wird weiter über Auslastung und Output gemessen statt über Wirkung.

Welche Kennzahlen misst man bei einer agilen Transformation?

Sinnvoll sind drei Ebenen. DORA-Metriken für die Lieferfähigkeit — Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service. Flow-Metriken für den Wertfluss über den gesamten Wertstrom, besonders Flow Time und Flow Efficiency. Und die vier Key Value Areas aus Evidence-Based Management für die Wirkung: Current Value, Unrealized Value, Time-to-Market und Ability-to-Innovate. Velocity gehört nicht dazu.

Welches Skalierungsframework ist das richtige?

Das hängt vom Ausgangszustand ab, und die Frage kommt meist zu früh. SAFe ist am anschlussfähigsten für Konzernstrukturen und erzeugt daher am wenigsten Widerstand, bringt aber viel Prozess mit. LeSS erzwingt echte Strukturveränderung und setzt entsprechende Bereitschaft voraus. Nexus ist schlank für drei bis neun Teams an einem Produkt. Wichtiger als die Wahl ist der Zuschnitt der Produkte und die Frage, ob überhaupt skaliert werden muss.

Welche Rolle hat das mittlere Management?

Eine zentrale, aber eine andere als bisher. Diese Ebene übersetzt Strategie in Prioritäten, räumt Hindernisse aus dem Weg, die Teams nicht selbst lösen können, und vermittelt zwischen Linien- und Produktlogik. Der Rollenwechsel geht vom Controller zum Enabler und vom Gatekeeper zum Brückenbauer — und er funktioniert nur, wenn Titel, Gehaltsband und Beförderungslogik nicht weiter an der Zahl der Unterstellten hängen.

Wie lange dauert eine agile Transformation?

In größeren Unternehmen mehrere Jahre, und ein definiertes Ende gibt es nicht. Erste messbare Effekte auf Teamebene zeigen sich meist nach zwei bis drei Quartalen; die Veränderung von Governance und Führungskultur braucht deutlich länger. Programme mit fixem Enddatum erzeugen typischerweise agiles Theater, weil zum Stichtag Vollzug gemeldet werden muss.