Wenn ein Framework das agile Arbeiten so weit „strukturiert“, dass kaum Raum f\u00fcr echte Iteration bleibt, wird es Zeit, genauer hinzusehen. Der Begriff „agil“ ist vielerorts noch pr\u00e4sent, doch die zugrundeliegende Praxis gleicht immer seltener dem, was einst als agiles Mindset gedacht war. SAFe steht dabei exemplarisch f\u00fcr diese Entwicklung.<\/p>\n
In vielen Unternehmen ist „Agile“ heute nicht mehr als ein neues Etikett auf alten Steuerungsmodellen. Der urspr\u00fcnglich aus der Softwareentwicklung stammende Versuch, Komplexit\u00e4t iterativ und empirisch zu beherrschen, wurde in zahlreichen F\u00e4llen \u00fcberlagert von administrativen Denkschulen, insbesondere aus dem mittleren Management.<\/p>\n
Das Ergebnis ist ein systematischer Bedeutungswandel: Selbstorganisation wird zum Mittel, um Verantwortung nach unten zu delegieren, ohne reale Entscheidungsspielr\u00e4ume zu geben. Transparenz wird zur Kontrolle, nicht zur Erkenntnis. Und empirisches Vorgehen wird durch vorgegebene „Best Practices“ ersetzt.<\/p>\n
Agile entstand 2001 mit dem „Manifesto for Agile Software Development“. Die dort formulierten Werte waren bewusst gegen klassische BWL-getriebene Projektsteuerung gerichtet: Interaktion statt Prozesse, funktionierende Software statt Dokumentation, Zusammenarbeit statt Vertragsverhandlung, Reagieren statt Planbefolgen.<\/p>\n
Frameworks wie Scrum oder XP \u00fcbernahmen diese Haltung in strukturierter Form. Doch mit dem Wachstum der agilen Bewegung entstand Druck, diese Konzepte in gro\u00dfen Organisationen zu skalieren. So entstand unter anderem SAFe (Scaled Agile Framework), das heute in vielen Konzernen eingesetzt wird.<\/p>\n
SAFe bringt ein strukturiertes Rollenmodell, Planungszyklen, Synchronisation \u00fcber „Agile Release Trains“ und umfangreiche Artefakte mit sich. Die offizielle Dokumentation beschreibt dies als „Lean-Agile approach at enterprise scale“ (scaledagileframework.com).<\/p>\n
Doch Kritiker wie Robert C. Martin und Dave Farley weisen darauf hin, dass dieser Ansatz in der Praxis oft zu einer Re-Administrierung f\u00fchrt, die den eigentlichen Kern agiler Methoden entwertet (Clean Agile, 2019; Modern Software Engineering, 2022).<\/p>\n
Zentrale Kritikpunkte sind unter anderem, dass durch Planungsdogmen ein faktisches Experimentierverbot entsteht, da anstelle iterativer Entwicklung die Planung auf Programmebene dominiert. Teams sollen sich selbst steuern, jedoch innerhalb enger Vorgaben und unter Beobachtung von Personen mit formaler Entscheidungsmacht. Der Begriff „PO“ ersetzt zwar formal den Projektleiter, \u00e4ndert jedoch nichts an der zugrundeliegenden Machtaus\u00fcbung. Dar\u00fcber hinaus entsteht durch zahlreiche Rollen und Meetings ein Bild von Agilit\u00e4t, das empirisch kaum wirksam wird, sondern vielmehr Komplexit\u00e4t simuliert.<\/p>\n
Diese Ph\u00e4nomene werden unter dem Begriff Dark Agile diskutiert: Ein Zustand, in dem die Terminologie agiler Methoden beibehalten wird, ihre Prinzipien aber ausgeh\u00f6hlt sind.<\/p>\n
Unternehmen, die weiterhin vom agilen Denken profitieren wollen, m\u00fcssen sich weniger mit Frameworks als mit Denkmodellen auseinandersetzen. Zentral ist dabei, dass Entscheidungen auf Basis von Hypothesenbildung, Experimenten und gemessenen Ergebnissen getroffen werden. Auch nicht-technische Rollen sollten Grundprinzipien wissenschaftlicher Arbeitsweise verinnerlichen, etwa die systematische Beobachtung, die saubere Ableitung von Ma\u00dfnahmen sowie die Offenheit f\u00fcr Korrektur. Das erfordert eine andere Haltung gegen\u00fcber Fehlern und Unsicherheit \u2013 eine Haltung, die eher im Engineering als in administrativen Routinen zu finden ist.<\/p>\n