Was ist das Scaled Agile Framework (SAFe)?
Das Scaled Agile Framework (SAFe) ist eine Wissensbasis aus organisatorischen und prozessualen Mustern, die großen Unternehmen hilft, Lean-, Agile- und DevOps-Praktiken über hunderte oder tausende Mitarbeitende hinweg anzuwenden. SAFe wurde 2011 von Dean Leffingwell entwickelt und koordiniert Arbeit über Agile Release Trains, Wertströme und vier Konfigurationsstufen, die zur jeweiligen Unternehmensgröße passen.
- Umfang und Ursprung: SAFe wurde 2011 von Dean Leffingwell entwickelt und wird von Scaled Agile, Inc. gepflegt, dem Unternehmen, das auch die Zertifizierungen vergibt und den Referenzleitfaden veröffentlicht.
- Verbreitung: Laut Scaled Agile haben 70 % der Fortune-100-Unternehmen zertifizierte SAFe-Fachkräfte im Einsatz, und weltweit wurden über 2 Millionen Praktiker geschult (Scaled Agile, 2024).
- Vier Konfigurationen statt einer: Essential, Large Solution, Portfolio und Full SAFe skalieren das Framework von einem einzigen Agile Release Train bis hin zu Multi-Portfolio-Unternehmen.
- Nicht unumstritten: Kritiker aus der Lean- und Kanban-Community argumentieren, dass SAFe Hierarchien und Zeremonien wieder einführt, die reines Scrum, das Spotify-Modell oder LeSS bewusst vermeiden.
Definition: Das Scaled Agile Framework (SAFe) ist eine Sammlung organisatorischer und prozessualer Muster, die Unternehmen dabei unterstützt, Lean- und Agile-Praktiken im großen Maßstab anzuwenden. SAFe verbindet Prinzipien aus Agile, Lean und Systemdenken zu einem strukturierten Rahmenwerk für agiles Arbeiten auf Unternehmensebene.
Kernkompetenzen, um die SAFe aufgebaut ist
SAFe baut auf einer überschaubaren Anzahl an Kernkompetenzen auf, die aus agilen Methoden, Systemdenken und Lean Product Development abgeleitet sind. Jede Kompetenz beschreibt eine Disziplin, die funktionieren muss, damit das Framework insgesamt Wert liefert.
- Lean-Agile Leadership: Führungskräfte treiben und tragen organisatorischen Wandel, indem sie Teams ausrichten und auf Ergebnisse statt auf Output coachen.
- Team and Technical Agility: Leistungsstarke agile Teams beherrschen die Engineering-Praktiken, das Testing und das handwerkliche Können, das für kontinuierliche Wertlieferung nötig ist.
- Agile Product Delivery: Kundenzentrierte Gestaltung, Release-Pipelines nach dem Prinzip „develop on cadence, release on demand" und feedbackgetriebene Verbesserung.
- Lean Portfolio Management: Finanzierung von Wertströmen statt Projekten, Steuerung über strategische Themen und Verwaltung des Portfolio-Kanbans.
- Continuous Learning Culture: Konsequente Verbesserung, Gewohnheiten einer lernenden Organisation und Innovationsrituale, die sich über die Zeit summieren.
So läuft ein SAFe-Rollout in der Praxis ab
Ein SAFe-Rollout folgt einer definierten zwölfstufigen Implementation Roadmap, die von Scaled Agile veröffentlicht wird. Hier ist sie auf die sechs Entscheidungen verdichtet, die darüber bestimmen, ob das Programm das erste Jahr übersteht.
- Den Kipppunkt erreichen. Benenne die brennende Plattform oder die proaktive Chance, die den Wandel rechtfertigt. Ohne dieses Momentum kommt der Rollout beim ersten Führungswechsel zum Stillstand.
- Lean-Agile Change Agents ausbilden. Zertifiziere SAFe Program Consultants (SPCs), die später Agile Release Trains coachen und PI Planning leiten.
- Ein Lean-Agile Center of Excellence aufbauen. Etabliere das kleine zentrale Team, das Standards, Schulungen und kontinuierliche Verbesserung über alle Trains hinweg verantwortet.
- Wertströme und ARTs identifizieren. Mappe, wie Wert zum Kunden fließt, und organisiere dann 50 bis 125 Praktiker pro Agile Release Train entlang dieses Flusses.
- Auf das Portfolio ausweiten. Führe Lean Portfolio Management, strategische Themen und das Portfolio-Kanban ein, sodass die Finanzierung Wertströmen statt Projekten folgt.
- Verstetigen und verbessern. Führe nach jedem Program Increment Inspect-and-Adapt-Workshops durch und betrachte das Framework selbst als Gegenstand kontinuierlicher Verbesserung.
Die vier SAFe-Konfigurationen im Vergleich
SAFe bietet vier Konfigurationen, damit das Framework zur tatsächlichen Größe des Unternehmens passt. Die Unterschiede sind nicht kosmetisch: Jede Konfiguration ergänzt spezifische Rollen, Zeremonien und Artefakte.
Konfiguration | Geltungsbereich | Trains | Ergänzt diese Elemente | Passt am besten zu |
|---|---|---|---|---|
Essential SAFe | Ein Agile Release Train | 1 ART (50 bis 125 Personen) | PI Planning, System Demo, Inspect and Adapt | Einzelnes Programm oder Produktlinie |
Large Solution SAFe | Mehrere ARTs liefern eine Lösung | 2 bis 10+ ARTs | Solution Train, Solution Architect, Solution Demo | Luft- und Raumfahrt, Verteidigung, komplexe Hardware |
Portfolio SAFe | Ein Portfolio aus Wertströmen | Mehrere ARTs im Portfolio | Lean Portfolio Management, strategische Themen, Portfolio-Kanban | Mittlere bis große Unternehmen |
Full SAFe | Multi-Portfolio-Unternehmen | Alles oben Genannte | Jede Rolle, jedes Artefakt und jede Kompetenz des Frameworks | Globale Unternehmen mit mehreren Portfolios |
Welche Probleme SAFe lösen soll
Die meisten Unternehmen führen SAFe ein, weil teamlevel-basierte agile Praktiken nicht mehr skalieren. Das Framework adressiert vier konkrete Fehlermuster, die ab etwa zehn Teams auftauchen.
- Mangelnde Ausrichtung zwischen Teams: PI Planning synchronisiert 50 bis 125 Personen rund um gemeinsame Program-Increment-Ziele, sodass Teams aufhören, Features zu bauen, die bei der Integration kollidieren.
- Langsame Release-Kadenz: Das Muster „develop on cadence, release on demand" entkoppelt Integration von Release, sodass alle zwei Wochen lauffähige Software existiert, selbst wenn das Business sich gegen einen Release entscheidet.
- Finanzierung an Projekten statt an Wert: Lean Portfolio Management finanziert langlebige Wertströme statt Einzelprojekten und nimmt damit den jährlichen Budgetzyklus vom kritischen Pfad.
- Keine Verbindung zwischen Strategie und Arbeit: Strategische Themen kaskadieren strategische Unternehmensziele über das Portfolio-Kanban hinunter in die ART-Backlogs.
Diese Verteidigung agiler Disziplin liegt im Kern dessen, warum SAFe existiert: Die Wette lautet, dass diszipliniertes Agile mit klar definierten Rollen und Kadenzen besser skaliert, als wenn jedes Team seinen eigenen Prozess erfindet.
Wo SAFe-Rollouts typischerweise scheitern
Das Framework deckt eine breite Oberfläche an Rollen, Artefakten und Zeremonien ab, was zugleich sein größtes Implementierungsrisiko ist. Vier Muster tauchen in gescheiterten Rollouts immer wieder auf.
- PI Planning wird zur Status-Sitzung. Zwei Tage synchronisierter Planung funktionieren nur, wenn die Teams mit vorbereiteten Features und klaren Akzeptanzkriterien anreisen. Ohne diese Vorbereitung verkommt das Event zu einer 100-Personen-Terminabstimmung.
- Zeremonie ohne Verhaltensänderung. Organisationen übernehmen Rollen und Meetings, behalten aber Wasserfall-Übergaben, meilensteinbasierte Finanzierung und Command-and-Control-Führung bei. Nach außen sieht es nach SAFe aus, das Betriebsmodell bleibt unverändert.
- Das Lean-Agile Center of Excellence wird zum Flaschenhals. Ein vierköpfiges LACE kann nicht jede Entscheidung jedes ART prüfen. Versucht es das, hören die Trains auf zu entscheiden und fangen an zu eskalieren.
- Anfangsinvestition unterschätzt. Die Zertifizierung von SPCs, das Umtrainieren von hunderten Praktikern und die ersten zwei bis drei Program Increments mit reduziertem Durchsatz sind reale Kosten. Rollouts, die diese Budgetzusage überspringen, kommen meist im neunten Monat zum Erliegen.
Wann SAFe die falsche Wahl ist
SAFe ist das am weitesten verbreitete Skalierungs-Framework und wird von etwa 35 % der Organisationen genutzt, die skaliertes Agile praktizieren (State of Agile Report, 2024). Trotzdem ist es nicht für jeden Kontext die richtige Antwort. In mindestens drei Situationen passt es schlecht.
- Kleine Organisationen. Unter 50 Ingenieuren übersteigt der Overhead aus Agile Release Trains, PI Planning und der SAFe-Rollenbibliothek den Koordinationsnutzen. Einfaches Scrum oder Kanban ist schneller.
- Produktorganisationen mit hoher Autonomie. Unternehmen, die sich über Engineering-Geschwindigkeit differenzieren (Consumer-SaaS, KI-Labs, Fintech-Challenger), stellen meist fest, dass das Spotify-Modell oder reine Team-of-Teams-Strukturen mehr Autonomie bewahren, als die vorgeschriebenen SAFe-Rollen zulassen.
- Häufige Strategie-Pivots. SAFe geht von einem Portfolio-Kanban mit strategischen Themen aus, die über mehrere Program Increments stabil bleiben. Organisationen, die jedes Quartal auf Basis neuer Marktdaten neu planen, sollten sich an quartalsweisen OKRs mit leichterer Koordination orientieren, nicht an jährlichen Portfolio-Kanbans.
Genau das ist die kritische Lesart, die SAFe-Kritiker seit dem Start des Frameworks vorbringen: Im großen Maßstab können die vorgeschriebenen Zeremonien jene Hierarchien und Übergaben wieder einführen, die teamlevel-Agile eigentlich beseitigen sollte.
Das Framework ist am stärksten in regulierten, mehrteamigen, mehrjährigen Lieferkontexten. Am schwächsten ist es dort, wo Geschwindigkeit beim strategischen Pivot der entscheidende Wettbewerbsvorteil ist.
SAFe im OKR-Zyklus einsetzen
Viele Unternehmen betreiben SAFe und OKRs parallel. Das sauberste Muster: SAFe als Ausführungsschicht behandeln und OKRs als die strategische Absicht darüber.
- Jährliche strategische Themen werden zu drei bis fünf OKRs auf Unternehmensebene.
- Portfolio-Kanban-Epics werden zu Key Results dieser OKRs, mit klar zugewiesenen Wertstrom-Verantwortlichen.
- Program-Increment-Ziele auf ART-Ebene leiten sich aus den Portfolio-OKRs ab und geben jedem Train einen messbaren Beitrag zu den Unternehmensergebnissen.
Diese Paarung erhält die Koordinationsstärke von SAFe und adressiert zugleich den häufigsten Kritikpunkt: dass strategische Themen allein Teams keine falsifizierbare Definition von Erfolg geben.
