Wieso agile Transformationen scheitern

Haben Sie je von einer wirklich gelungenen agilen Transformation gehört? Die meisten zögern bei der Antwort. Das hat einen Grund — und er liegt selten dort, wo man ihn sucht.

Fragt man, warum es nicht klappt, kommen meist dieselben Antworten: Den Leuten fehle das agile Mindset. Man habe nicht die richtigen Menschen, sie würden keine Verantwortung übernehmen. Das mittlere Management blockiere. Erst müsse die Kultur reifen.

Klingt plausibel — und führt in die Irre. Menschen sind nie das Problem. Sie verhalten sich so, wie die geltenden Regeln es nahelegen. Wer die Ursache bei den Menschen sucht, verstellt sich den Blick auf die eigentliche Quelle: das System, das dieses Verhalten erzeugt. Immer wenn von Mindset, Reifegrad oder Kulturarbeit die Rede ist, lohnt es innezuhalten — hier wird an der falschen Stelle gesucht.

Führt man agiles Arbeiten in einzelnen Teams oder Abteilungen ein, entsteht ein Spannungsfeld. Im ganzen Unternehmen gelten weiter die alten Prinzipien: zentrale Steuerung, Standardisierung, Budgets, Planung — alles, was die Sozialtechnologie Management ausmacht. Auf einer Insel daneben soll plötzlich das Gegenteil gelten: Selbstorganisation, dezentrale Entscheidung, Fokus auf Wirksamkeit statt Auslastung.

Zwei Regelwerke, die einander widersprechen, im selben Haus. Diese Inkonsistenz verschwindet nicht von selbst. Sie muss dauernd ausbalanciert werden — und genau daran zehrt jede agile Transformation.

Die Führungskraft über einem agilen Team steckt mittendrin. Sie soll dem Team die Selbststeuerung überlassen — ist aber selbst ihren Vorgesetzten gegenüber an die alten Prinzipien gebunden. Frei ist sie nicht. Also steuert sie gegen, sobald Planbarkeit verlangt wird, und das Team erlebt Verwirrung statt Verlässlichkeit.

In Scrum gibt es dafür eine eigene Rolle, den Scrum Master, der diese Inkonsistenz ständig abfedert. Der Stammtisch bringt es auf den Punkt: „Ein guter Scrum Master ist bereits halb gefeuert.“ Und für Führungskräfte wurden eigene Zertifikate erfunden, „Certified Agile Leadership“ und dergleichen. Auch das verlegt das Problem an die falsche Adresse: Es unterstellt, die Führungskraft sei der Fehler. Ist sie nicht. Sie sitzt nur an einer Stelle, an der sich der Konflikt nicht lösen lässt.

Denn der Widerspruch entsteht eine Ebene höher — dort, wo die Regeln für das ganze Unternehmen gesetzt werden. Auflösen lässt er sich nur dort. Diese Ebene sind Sie.

Der naheliegende Ausweg: das Spannungsfeld vermeiden, bei den alten Prinzipien bleiben und nur die Werkzeuge übernehmen. Kanban-Board, Daily, Sprints — aber mit Teamlead, Vorgaben und ohne Selbststeuerung. Dann wird das Stand-up zum Reporting, das Backlog füllt der Product Owner, die Tickets verteilt der Teamlead mit Deadline.

Heraus kommt keine lernende, wirksame Organisation, sondern mehr Aufwand bei gleicher Logik. Engagement sinkt, Frust steigt, die Kennzahlen zeigen nach unten. Das Fazit der Beteiligten lautet dann: „Agil funktioniert nicht.“ Dabei wurde Agilität nie wirklich zugelassen.

Das Management hat vor über hundert Jahren als Quantensprung begonnen. Frederick Taylors „Scientific Management“ von 1911 war für einen stabilen, planbaren Markt genau richtig: Zentralisierung, Standardisierung, Planung. Seither wurde es bestenfalls optimiert — und bildet bis heute die DNA der meisten Unternehmen.

Nur ist der Markt nicht mehr stabil. Er ist volatil, schnell, komplex. Was damals trug, bremst heute. Die saubere Antwort ist deshalb nicht, einzelne Teams „agil zu machen“, sondern das ganze Organisationsdesign neu auszurichten. Eine agile Transformation optimiert das alte System — überwinden kann sie es nie. Genau das ist der Unterschied, an dem sie scheitert.

Diesen Schritt kann niemand im Unternehmen aus eigener Kraft gehen. Er braucht jemanden, der die Regeln des Ganzen ändern darf — und will. Welcher Prinzipiensatz den tayloristischen ablösen kann, ist gut erprobt; der BetaCodex ist einer davon. Aber das ist der zweite Schritt. Der erste ist die Entscheidung, überhaupt am System zu arbeiten statt nur in ihm.

Welches Framework Sie wählen, ist am Ende zweitrangig. Die eigentliche Frage ist eine andere: Wollen Sie die Spielregeln Ihres Unternehmens ändern — oder im Bestehenden besser werden?

Wer das Erste will, kommt ums Denken nicht herum. Aber er hört auch auf, gegen Windmühlen zu balancieren.