SAFe ist der Versuch, agiles Arbeiten auf die gesamte Organisation auszudehnen – nicht nur auf einzelne Teams. Ein ambitioniertes Unterfangen, das in grossen Organisationen echten Nutzen stiftet und in kleinen oft mehr kostet als es bringt.
Was bedeutet SAFe?
SAFe (Scaled Agile Framework) ist ein Rahmenwerk zur Skalierung agiler Prinzipien über Team-, Programm- und Unternehmensebene hinweg. Es wurde von Dean Leffingwell entwickelt und kombiniert Elemente aus Scrum, Lean Management, Kanban und Systemdenken zu einem integrierten Modell für grosse, komplexe Organisationen.
Im Kern beantwortet SAFe eine Frage, die viele Unternehmen quält: Wie arbeiten wir agil, wenn wir nicht zehn, sondern zweihundert Menschen koordinieren müssen – über Abteilungen, Standorte und Hierarchieebenen hinweg? SAFe schafft dafür eine gemeinsame Sprache, klare Rollen, synchronisierte Planungsrhythmen und eine durchgängige Ausrichtung auf strategische Ziele.
Methodisch fusst SAFe auf drei Wissenskörpern: dem Agilen Manifest, dem Lean-Produktentwicklungsgedanken (nach Reinertsen und Ward) sowie dem Systemdenken (nach Deming und Senge). Diese Kombination ist kein Zufall – sie erklärt, warum SAFe in seiner Tiefe weit über klassisches Projektmanagement hinausgeht.
SAFe im Unternehmensalltag
Ein Versicherungskonzern mit 15 Entwicklungsteams möchte quartalsweise neue Produkte launchen, scheitert aber daran, dass Teams aneinander vorbeiarbeiten, Abhängigkeiten spät erkannt werden und die strategische Ausrichtung auf Teamebene kaum ankommt. SAFe adressiert genau das: durch synchronisierte Planungszyklen (Program Increments), gemeinsame Backlogs auf Programmebene (ART – Agile Release Train) und eine durchgängige Verbindung von Strategie bis zur Teamarbeit.
Das zentrale Planungselement ist das PI Planning (Program Increment Planning): ein zweitägiger Workshop, in dem alle Teams gemeinsam planen, Abhängigkeiten sichtbar machen und sich auf gemeinsame Ziele ausrichten. Wer dieses Format einmal erlebt hat, versteht, warum es als einer der wirksamsten Koordinationsmechanismen in grossen Organisationen gilt.
Für wen lohnt sich SAFe – und für wen nicht?
SAFe lohnt sich, wenn mehrere dieser Merkmale zutreffen:
Die Organisation hat mehr als 50–100 Personen in der Produkt- oder Lösungsentwicklung. Es gibt mehrere Teams, die an gemeinsamen Produkten oder Plattformen arbeiten und voneinander abhängig sind. Klassische Planungsansätze scheitern regelmässig an Koordinationsproblemen zwischen Teams. Es besteht der Wille, Strategie und operative Arbeit systematisch zu verbinden. Die Führungsebene ist bereit, Autonomie abzugeben und Rahmenbedingungen statt Detailaufgaben zu definieren.
SAFe lohnt sich nicht, wenn das Unternehmen klein ist, wenige Teams hat oder die Herausforderung primär in ineffizienten Prozessen liegt – und nicht in der Skalierungsproblematik. Hier wirken Prozessoptimierung und Kaizen wirkungsvoller und mit deutlich weniger Einführungsaufwand. SAFe ist kein Allheilmittel – es ist ein Präzisionsinstrument für ein spezifisches Problem.
SAFe und Lean – eine bewusste Verbindung
SAFe ist explizit lean-basiert. Die Lean-Prinzipien – Wertschöpfung aus Kundensicht, Fluss, Pull, Perfektion und Respekt vor Menschen – sind direkt in das Framework eingebettet. Das ist kein Zufall: Grosse Organisationen scheitern bei agilen Transformationen häufig nicht an der Methodik, sondern an aufgeblähten Strukturen, unklaren Verantwortlichkeiten und fehlender strategischer Ausrichtung. Genau hier setzt die Lean-Logik an.
Besonders sichtbar wird die Lean-Verbindung im Konzept des Continuous Flow: SAFe zielt darauf ab, Entwicklungsarbeit in einem gleichmässigen, vorhersehbaren Fluss zu halten – analog zum Taktprinzip in der Lean-Produktion. Engpässe, Wartezeiten und Überlastung werden sichtbar gemacht und systematisch reduziert. Das erinnert stark an die Wertstromanalyse – nur auf Programm- statt Prozessebene.
Die aktuellen Weiterentwicklungen des Frameworks gehen in Richtung Business Agility: SAFe dehnt sich zunehmend auf nicht-technische Bereiche aus – HR, Finanzen, Recht, Marketing. Die Erkenntnis dahinter: Agilität in der Entwicklung nützt wenig, wenn das Umfeld nach wie vor in Jahresbudgets und starren Strukturen denkt.