Agile transformation: die 5 Werte, die 6 Prinzipien – und warum trotzdem zwei Drittel scheitern
Ein Kundentermin, an den ich mich erinnere, als wäre es gestern: Ein mittelständischer Maschinenbauer, 340 Mitarbeitende, zwei Jahre „Agile Transformation" hinter sich. Vierzehn Scrum-Teams. Ein hauseigener Agile Coach, der inzwischen mehr Zeit mit Jira-Konfiguration als mit Menschen verbrachte. Und die Geschäftsführung fragte in der Runde ernsthaft: „Wann fangen wir an, schneller zu werden?"
Das ist der Moment, in dem ich anfange, nervös zu werden. Nicht weil agile transformation kompliziert wäre. Sondern weil die meisten Organisationen glauben, sie hätten sie längst verstanden.
Ich habe in den letzten Jahren gut zwei Dutzend Transformationen begleitet – mal als Berater, mal als Projektleiter, der es selbst verbockt hat. Die ehrliche Bilanz: Bei etwa einem Drittel hat es wirklich funktioniert. Beim Rest wurde ein Framework installiert, ein Budget verbraucht und ein Begriff gelernt. Das „agil" blieb ein Etikett.
Wichtige Erkenntnisse
- Die 5 agilen Werte sind das Fundament – Scrum und Kanban sind nur Werkzeuge, die darauf aufsetzen.
- Die 6 agilen Prinzipien beschreiben, wer wie zusammenarbeitet – nicht, welches Tool Sie einführen.
- Agile transformation bedeutet kulturellen Wandel, nicht Methodenwechsel: Wer nur Rituale kopiert, bekommt Rituale ohne Wirkung.
- Der häufigste Grund zu scheitern ist nicht Widerstand der Teams, sondern die Geschäftsführung, die selbst nicht mitgeht.
- Feste Kennzahlen (Durchlaufzeit, Lieferhäufigkeit, Zufriedenheit) schlagen jede PowerPoint-Fortschrittsanzeige.
Was versteht man unter agile? Mehr als ein Methodenbaukasten
Agile ist zuerst einmal eine Haltung. Genauer: ein Satz von Überzeugungen darüber, wie man mit Unsicherheit umgeht. Der Ursprung liegt im Agilen Manifest – geschrieben 2001 von siebzehn Praktikern, die genug davon hatten, dass Projekte monatelang an Anforderungsdokumenten scheiterten, bevor die erste Zeile Code entstand.
Der Kern in einem Satz: Wir erkennen Unsicherheit an und bauen darauf, statt sie wegzuplanen.
Was agile nicht ist: ein Freibrief für Regellosigkeit. Das ist der häufigste Irrtum, dem ich in Vorstandsetagen begegne. „Agil heißt doch, dass jeder macht, was er will" – nein. Agil heißt, dass das Team entscheidet, wie es arbeitet, während das Was weiterhin aus dem Geschäft kommt. Ohne diese Trennung wird agil zur Ausrede.
Agile transformation ist nicht digitale Transformation
Die beiden werden ständig in einen Topf geworfen. Sind sie aber nicht, und der Unterschied ist praktisch wichtig:
- Digitale Transformation ändert, was Sie verkaufen und wie es zum Kunden kommt – Geschäftsmodell, Kanäle, Systeme.
- Agile transformation ändert, wie Ihre Organisation Entscheidungen trifft und Arbeit erledigt.
Man kann agil arbeiten und völlig analoge Produkte verkaufen. Man kann ein hochdigitales Geschäftsmodell haben und trotzdem wasserfallartig steuern. Beides passiert regelmäßig, und beides ist ein Problem.
Was sind die 5 agilen Werte?
Die fünf agilen Werte bilden das Fundament agiler Zusammenarbeit. Sie sind bewusst als Gegenüberstellungen formuliert – das ist der entscheidende Punkt, den viele überlesen. Es geht nicht um entweder/oder, sondern um eine Gewichtung: Beide Seiten haben Wert, aber die linke Seite hat im Zweifel den Vorrang.
- Individuen und Interaktionen stehen über Prozessen und Werkzeugen. Ein perfekt konfiguriertes Board bringt nichts, wenn niemand miteinander redet.
- Funktionierende Ergebnisse stehen über umfassender Dokumentation. Dokumentation ist wichtig – aber ein Dokument, das niemand liest, ersetzt kein laufendes Produkt.
- Zusammenarbeit mit dem Kunden steht über Vertragsverhandlungen. Das heißt nicht, Verträge zu ignorieren. Es heißt, bei Konflikten gemeinsam nach einer Lösung zu suchen statt auf Paragrafen zu pochen.
- Reaktion auf Veränderung steht über dem Befolgen eines Plans. Pläne sind nützlich, bis die Realität sie überholt.
- Und der fünfte Wert, der oft vergessen wird: Selbstorganisation. Teams organisieren ihre Arbeit selbst, statt Anweisungen von oben zu erwarten.
Ehrlich gesagt: Punkt fünf ist der, an dem es in der Praxis am häufigsten bricht. Nicht weil Teams nicht wollen. Weil Führungskräfte das Loslassen nicht aushalten.
Wie sich Werte im Alltag reiben
Ich saß mal in einem Steering Committee, in dem ein Programmleiter stolz ein 40-seitiges Reporting zeigte – während im Raum daneben das Entwicklungsteam seit zwei Wochen auf eine Entscheidung wartete, die keiner treffen wollte. Der Widerspruch zwischen Wert eins und der gelebten Praxis hätte nicht größer sein können. Das Team hieß agil. Es war es nicht.
Solche Momente sind der eigentliche Test. Nicht die Retrospektive. Nicht die Zertifikate. Sondern die Frage: Wer entscheidet, wenn es weh tut?
Was sind die 6 wichtigsten agilen Prinzipien?
Hinter dem Manifest stehen zwölf Prinzipien. Sechs davon tragen in der Praxis den größten Teil der Wirkung, weil sie direkt beschreiben, wie Arbeit fließen soll.
Kunden durch frühe und kontinuierliche Lieferung wertvoller Software zufriedenzustellen: Das heißt nicht „mehr Auslieferungen", sondern Lieferungen, die jemand tatsächlich nutzt. Ich habe Teams gesehen, die Releases im Wochentakt produzierten, von denen die Hälfte nie ausgerollt wurde. Häufigkeit ohne Wert ist Beschäftigungstherapie.
Die sechs Prinzipien im Überblick (zum Aufklappen)
- Frühe und kontinuierliche Lieferung von Wert an den Kunden.
- Veränderte Anforderungen sind willkommen – auch spät im Projekt.
- Funktionierende Ergebnisse werden in kurzen Abständen geliefert (Wochen, nicht Monate).
- Fachleute und Auftraggeber arbeiten täglich zusammen.
- Projekte entstehen um motivierte Menschen herum, denen man vertraut.
- Regelmäßige Reflexion: Das Team hinterfragt sein Vorgehen und passt es an.
Prinzip 6 ist das unterschätzte
Punkt sechs, die regelmäßige Reflexion, ist der Motor. Ohne ihn werden alle anderen Prinzipien statisch: Man führt einmal ein, was gut klingt, und merkt drei Jahre später nicht, dass die Welt sich weitergedreht hat. Retrospektiven, die zu reinen Statusrunden verkommen, sind der sichtbarste Hinweis darauf, dass eine Transformation gerade einschläft.
Was funktioniert: eine einzige Frage, ehrlich beantwortet. „Was hat uns diese Woche ausgebremst?" Nicht mehr. Aus der Antwort folgt fast immer der nächste Schritt von allein.
Warum scheitern Agile Projekte? Vier Ursachen, die ich ständig sehe
Die häufigste Antwort, die man hört: „Die Teams waren noch nicht so weit." In meiner Erfahrung ist das fast nie der Grund. Die Gründe liegen weiter oben.
| Ursache | Wie es sich zeigt | Typischer Zeitpunkt |
|---|---|---|
| Führung geht nicht mit | Teams entscheiden dürfen, aber jede größere Entscheidung wird zurückgeholt | Monat 4–8 |
| Agile als Kostenprogramm | Die Transformation wird mit einem Sparziel verkauft, nicht mit einem Kundenziel | von Anfang an |
| Rituale ohne Werte | Daily, Review, Retro laufen – aber niemand hinterfragt, wozu | nach der ersten Welle |
| Kein Messbares | Fortschritt wird in Trainings und Zertifikaten gemessen, nicht in Lieferzeit | durchgehend |
Bei einem meiner eigenen Projekte – ein Softwarehaus mit 60 Leuten, das ich vor einigen Jahren begleitete – scheiterte es an Ursache eins. Wir hatten alles richtig aufgesetzt: sieben Teams, ein gemeinsamer Backlog, zweiwöchentliche Reviews. Nach fünf Monaten stellte ich fest, dass der Bereichsleiter die Priorisierung weiterhin selbst vornahm, ohne das Product Owner-Team einzubeziehen. Die Teams lieferten sauber. Nur eben nicht das, was wir gemeinsam beschlossen hatten. Die Transformation war formal erfolgreich und praktisch wirkungslos.
Kurz gesagt: Wenn die Hierarchie nicht mitgeht, gewinnt sie immer. Sie muss es nur nicht laut sagen.
Was stattdessen hilft
Drei Dinge, die in den Fällen, in denen es funktioniert hat, den Unterschied machten:
- Die Geschäftsführung änderte ihr eigenes Verhalten, nicht nur ihre Sprache. Konkret: weniger Statusberichte, mehr direkte Fragen an die Teams.
- Es gab genau zwei Kennzahlen: Durchlaufzeit einer Anforderung und Anzahl der Lieferungen pro Monat. Keine zwanzig.
- Man ließ bewusst Dinge weg. Kein neues Portfolio-Tool, keine Zertifizierungswelle, keine Umbenennung von Abteilungen in „Chapters".
Der letzte Punkt klingt banal. In der Praxis ist er der schwerste: Transformationen scheitern selten an fehlenden Maßnahmen, sondern an zu vielen.
Was am Ende bleibt
Agile transformation ist kein Ziel, das man erreicht. Sie ist eine Praxis, die man entweder weiterbetreibt oder nicht. Das erklärt auch, warum die Frage „Sind wir jetzt agil?" so unangenehm ist – sie sucht nach einem Endpunkt, den es nicht gibt.
Die interessantere Frage wäre: Woran würden wir merken, dass wir aufhören, uns zu verbessern? Wer darauf eine ehrliche Antwort hat, braucht die andere Frage nicht.
