SAFe – viel genutzt, viel kritisiert. Aber warum eigentlich?

Das Scaled Agile Framework (SAFe) gehört heute zu den am weitesten verbreiteten Frameworks für die Skalierung agiler Arbeitsweisen. Vor allem in Konzernen und stark regulierten Branchen findet SAFe Anwendung. Gleichzeitig ist kaum ein Framework so umstritten: Für die einen ist es ein praktikabler Weg, agile Prinzipien unternehmensweit zu etablieren – für die anderen ein überladener Methodenkatalog, der mit echter Agilität wenig zu tun hat.

Doch woher kommt diese Kritik?

Zum einen liegt es an der schieren Komplexität des Frameworks: Rollen, Artefakte, Ebenen, Prozesse – SAFe wirkt schnell wie ein Baukasten für Bürokratie statt für Beweglichkeit. Viele erleben die Einführung von SAFe als top-down getrieben, mit großem Schulungs- und Zertifizierungsaufwand, aber wenig greifbarer Veränderung im Alltag.

Zum anderen wird SAFe in der Praxis oft nicht situativ und kontextsensibel adaptiert, sondern als Blaupause eingeführt. Und das unabhängig davon, ob die Organisation kulturell, strukturell oder vom Reifegrad her überhaupt dazu passt. Die Folge: Rollen bleiben unbesetzt, Events werden abgehalten, ohne dass sie echten Mehrwert bringen, und das PI Planning wird zur reinen Kalenderübung.

Nicht selten hört man dann Aussagen wie:
🗯️ „Wir haben SAFe eingeführt – aber wirklich agil sind wir deshalb nicht geworden.“
🗯️ „SAFe ist nur alter Wasserfall in neuem Gewand.“
🗯️ „Das ist doch nur ein Zertifizierungs-Business.“

Dabei ist weniger das Framework selbst das Problem – sondern die Art und Weise, wie es eingeführt wird. Denn SAFe ist kein Allheilmittel, sondern ein Werkzeugkasten. Und wie bei jedem Werkzeug gilt: Entscheidend ist, wofür und wieman es einsetzt.

Genau deshalb lohnt sich ein genauer Blick auf gelungene Adaptionen. Wie kann SAFe dort wirksam sein, wo es echte Probleme löst? Welche Faktoren führen zum Erfolg? Und was lässt sich daraus lernen – auch jenseits von SAFe?

Ein Beispiel dafür liefert ein Wohnbaufinanzierer. Dort wurde SAFe nicht lehrbuchmäßig, sondern ganz bewusst bottom-up eingeführt – aus dem echten Bedarf heraus. Und genau diese situative, anpassungsfähige Herangehensweise hat den Unterschied gemacht.

Wie sieht eine erfolgreiche SAFe-Adaption in der Praxis aus?

Ein besonders spannendes Beispiel kommt aus der Finanzbranche – genauer gesagt einer Bausparkasse. Bereits im Jahr 2017 begannen dort erste Bereiche, agile Arbeitsweisen einzuführen. Damals war SAFe in Deutschland noch wenig verbreitet, und viele Berater empfahlen ein möglichst konsequentes Top-down-Vorgehen. Der Wohnbaufinanzierer wählte bewußt einen anderen Weg.

Statt das Framework flächendeckend „auszurollen“, entschied sich ein cross-funktionales Cluster aus Fach- und IT-Bereich für einen situativen, bedarfsgerechten Einsatz einzelner SAFe-Elemente – angepasst an die konkreten Herausforderungen vor Ort. Die Einführung erfolgte bottom-up, initiiert von Führungskräften, die echten Veränderungswillen mitbrachten und ihre Teams auf dem Weg mitnahmen.

Ich selbst war damals als Verantwortlicher für das Cluster Business Intelligence beteiligt – und habe erlebt, wie kraftvoll dieser Ansatz sein kann, wenn man ihn richtig aufsetzt.

Was hat funktioniert? Kritische Erfolgsfaktoren aus der Praxis

🔹 Orientierung statt Dogmatik
Wir haben SAFe nicht als „heilige Schrift“ betrachtet, sondern als Werkzeugkiste. Was uns geholfen hat, haben wir übernommen – den Rest weggelassen. Zum Beispiel PI Planning, ARTs, gemeinsame Backlogs – ja. Aber keine überflüssige Bürokratie oder Rollenbesetzungen, die nicht zum Setup passten.

🔹 Problemorientierter Einsatz
SAFe wurde dort genutzt, wo es echte Probleme löste: fehlende Abstimmung, unklare Prioritäten, mangelnde Transparenz zwischen Fachbereich und IT. Die Lösung stand nie im Vordergrund – das Problem tat es.

🔹 Starke Unterstützung von oben
Auch wenn die Initiative bottom-up gestartet wurde, war die Unterstützung des CIOs und CFOs ein Schlüsselfaktor. Gerade das PI Planning wurde durch ihre Teilnahme und Unterstützung aufgewertet und gab den Teams ein starkes Signal.

🔹 Schulungen ja – aber mit Augenmaß
Wir haben in gezielte Schulungen investiert, aber den Fokus auf das gemeinsame Verständnis gelegt, nicht auf Zertifikate. Interne Coaches begleiteten die Einführung, externe Unterstützung war punktuell – nicht dauerhaft.

🔹 Interne Rollenbesetzung
Rollen wie Product Owner oder Release Train Engineer wurden intern besetzt. Das sorgte für Praxisnähe, Akzeptanz – und langfristige Wirksamkeit. Externe Coaches wurden bewusst nicht als „Vordenker“, sondern als Sparringspartner eingesetzt.

🔹 Agile Werte und Prinzipien gelebt, nicht nur gepredigt
Neben der Einführung struktureller Elemente wie Rollen, Prozessen und Events haben wir uns bewusst auch mit dem Fundament von SAFe beschäftigt: den agilen Werten, Prinzipien und dem zugrunde liegenden Führungsverständnis.

In einer gemeinsamen Workshopreihe – Fachbereiche und IT zusammen – haben wir intensiv reflektiert: Was bedeutet Führung in einer agilen Organisation wirklich? Welche Werte sind uns als Cluster wichtig? Und noch wichtiger: Was können und müssen wir – jede:r Einzelne – konkret dafür tun?

Diese Auseinandersetzung war kein „Soft-Skill-Add-on“, sondern zentraler Bestandteil der Transformation. Sie schuf ein gemeinsames Verständnis, Vertrauen – und die Basis für eine wirklich gelebte Zusammenarbeit auf Augenhöhe.
Oft sogar im selben Raum. Täglich. Pragmatismus statt Prinzipienreiterei. Austausch statt Abgrenzung. Das war für viele ein echter Wendepunkt.

Was wir heute daraus ableiten – und warum situativer Methodeneinsatz so entscheidend ist

Die erfolgreiche Adaption zeigt: Nicht das Framework entscheidet über Erfolg oder Misserfolg, sondern der Umgang damit. Oder anders gesagt: Es kommt nicht darauf an, ob man SAFe nutzt – sondern wie.

Genau hier knüpft übrigens auch unser Solution Pattern 8: Situativer Methodeneinsatz an. Es beschreibt, wie Organisationen nicht Methoden „einführen“, sondern gezielt nutzen – ausgehend vom Problem, dem Reifegrad und der konkreten Situation vor Ort.

Wer dieses Prinzip ernst nimmt, erkennt: SAFe kann ein wertvoller Teil der Lösung sein – aber nur, wenn es kein Selbstzweck ist.

Fazit: Nicht ob – sondern wie.

Die erfolgreiche Adaption bei dem Finanzdienstleister zeigt eindrücklich: SAFe funktioniert dann wenn man es nicht als Dogma, sondern als Denk- und Werkzeugkasten versteht. Der Schlüssel liegt im situativen Methodeneinsatz – aber vor allem in der bewussten Auseinandersetzung mit Werten, Prinzipien und dem eigenen Führungsverhalten.

Nicht das Framework verändert die Organisation – die Menschen tun es.
Und das beginnt mit der Frage: Worauf wollen wir unsere Zusammenarbeit bauen – und wie handeln wir danach?

Dass dieser Weg wirkt, zeigt sich auch im Ergebnis: Aus ursprünglich zwei Clustern sind fünf Agile Release Trains entstanden – darunter auch der IT-Betrieb.
Alle arbeiten heute entlang des SAFe-Modells – angepasst an ihren Kontext.
Die Prinzipien wurden nicht nur eingeführt – sie wurden nachhaltig verankert.