SAFe: agile Arbeit über viele Teams skalieren
https://bildung.social/@oerinformatik/
https://oer-informatik.de/safe
SAFe, Scaled Agile Framework, Vorgehensmodelle, Agile Release Train, PI Planning, Planning Interval, Release Train Engineer, Skalierung, Lean Portfolio Management, agile Softwareentwicklung
tl/dr; (ca. 13 min Lesezeit): Das Scaled Agile Framework (SAFe) überträgt agile Arbeit von einzelnen Teams auf ganze Organisationen: Mehrere agile Teams bilden einen Agile Release Train, der im gemeinsamen Takt von Planning Intervals plant, integriert und liefert. Der Artikel erklärt Herkunft, Werte und Konfigurationen von SAFe 6.0, den Ablauf mit PI Planning, System Demo und Inspect & Adapt, die wichtigsten Rollen und Artefakte, Kennzahlen sowie die Kritik am Framework [AI-Assisted]. (Zuletzt geändert am 30.10.2026)
Disclaimer: Teile des Textes stammen von einer KI. Inhalte sind nicht automatisch zuverlässig; überprüfe Fakten und zitiere vertrauenswürdige Quellen.
Dieser Artikel ist Teil einer Artikelreihe über Vorgehensmodelle: Überblick: klassisch und agil / Wasserfallmodell / V-Modell / Spiralmodell / Scrum / Extreme Programming / Kanban / SAFe / DevOps / Übungsaufgaben
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Dieser Artikel baut auf der Kann-Liste der Artikel Vorgehensmodelle: klassisch und agil und Scrum auf.
Als Projektmanagement-Grundlagen kann ich nach Durchlesen des Artikels…
… erklären, wozu skalierte agile Rahmenwerke wie SAFe dienen.
… den Agile Release Train und das Planning Interval beschreiben.
… die Ereignisse PI Planning, System Demo und Inspect & Adapt erläutern.
… die Rollen Release Train Engineer, Product Management, System Architect und Business Owner von den Rollen auf Teamebene unterscheiden.
Darüber hinaus kann ich als Projektmanagement-Expertenwissen…
… die vier Konfigurationen von SAFe und die Hierarchie von Epics, Features und Stories erläutern.
… Kritik an SAFe wiedergeben und SAFe von anderen Skalierungsrahmen (LeSS, Nexus) abgrenzen.
In einem Satz: SAFe zeichnet sich dadurch aus, dass viele agile Teams zu einem Agile Release Train zusammengefasst werden, der in einem gemeinsamen Takt von meist acht bis zwölf Wochen plant, ein integriertes Gesamtsystem vorführt und seine Arbeit an der Strategie des Unternehmens ausrichtet.
SAFe ist in Ebenen aufgebaut: Agile Teams arbeiten mit Scrum, Kanban und XP-Praktiken; darüber koordiniert der Agile Release Train die Teams; bei Bedarf kommen eine Ebene für sehr große Systeme und eine Portfolio-Ebene für Strategie und Budget hinzu.
Herkunft: Agilität für Großunternehmen
SAFe wurde von Dean Leffingwell entwickelt, der agile Praktiken für große Organisationen bereits 2007 und 2011 in Büchern beschrieb („Scaling Software Agility“, „Agile Software Requirements“). Die erste Fassung des Frameworks erschien 2011; herausgegeben und weiterentwickelt wird es von der Firma Scaled Agile, Inc., aktuell als SAFe 6.0 (März 2023). SAFe verbindet Elemente aus Scrum, Kanban, XP, Lean Management, DevOps und Systemdenken. Ziel ist, dass Hunderte oder Tausende Menschen, die gemeinsam an großen Produkten arbeiten, wie agile Teams im gleichen Takt planen, liefern und lernen – und dass die Arbeit an der Unternehmensstrategie ausgerichtet bleibt. Typische Einsatzbereiche sind Großunternehmen, Banken und Versicherungen, Automobilindustrie, Telekommunikation und Behörden.
Grundprinzipien: Werte, Lean-Agile-Prinzipien, Kompetenzen
SAFe 6.0 nennt vier Kernwerte: Ausrichtung (Alignment: alle arbeiten an denselben Zielen), Transparenz (Transparency), Respekt vor Menschen (Respect for People) und ständige Verbesserung (Relentless Improvement). Dazu kommen zehn Lean-Agile-Prinzipien, etwa:
wirtschaftlich denken (Entscheidungen nach Kosten der Verzögerung),
Systemdenken (das Gesamtsystem optimieren, nicht einzelne Teams),
schrittweise mit schnellen, integrierten Lernzyklen entwickeln,
Meilensteine auf objektive Bewertung funktionierender Systeme stützen,
im Takt arbeiten und teamübergreifend synchronisieren (Cadence),
Entscheidungen dezentralisieren.
Sieben Kernkompetenzen (u. a. Team and Technical Agility, Agile Product Delivery, Lean Portfolio Management) beschreiben, was eine Organisation dafür können muss. Besonders an SAFe ist die vollständige Beschreibung aller Ebenen – vom einzelnen Team bis zum Budget des Portfolios – mit festen Rollen, Ereignissen und Artefakten.
Ablauf: das Planning Interval
Der zentrale Takt ist das Planning Interval (PI, bis SAFe 5 Program Increment): meist acht bis zwölf Wochen, typischerweise vier Entwicklungsiterationen von je zwei Wochen und eine IP-Iteration (Innovation and Planning) zum Abschluss.
PI Planning: Alle Teams des Release Trains planen zwei Tage lang gemeinsam (vor Ort oder online) das nächste PI. Product Management stellt Vision und priorisierte Features vor, die Teams planen ihre Iterationen, decken Abhängigkeiten auf und formulieren PI-Ziele; die Business Owners bewerten die Ziele.
Iterationen: Jedes Team arbeitet in seinen Iterationen wie ein Scrum- oder Kanban-Team (Iteration Planning, Team Sync, Iteration Review, Retrospektive).
ART Sync: regelmäßige Abstimmung der Teams (Coach Sync der Scrum Master und PO Sync der Product Owner).
System Demo: Am Ende jeder Iteration wird das integrierte Gesamtsystem vorgeführt – nicht nur die Ergebnisse einzelner Teams.
Inspect & Adapt (I&A): Am Ende jedes PI werden das Gesamtergebnis vorgeführt, Kennzahlen ausgewertet und in einem strukturierten Problemlösungs-Workshop Verbesserungen beschlossen.
Das Aktivitätsdiagramm zeigt den Ablauf eines PI mit den Artefakten:
Rollen: Team, Train und Portfolio
| Ebene | Rolle | Aufgabe |
|---|---|---|
| Team | Agile Team | höchstens etwa zehn Personen, funktionsübergreifend, liefert Stories |
| Team | Product Owner | pflegt das Team Backlog, verantwortet die Stories |
| Team | Scrum Master / Team Coach | unterstützt das Team, beseitigt Hindernisse |
| ART | Release Train Engineer (RTE) | moderiert die ART-Ereignisse, beseitigt teamübergreifende Hindernisse („Scrum Master des Trains“) |
| ART | Product Management | verantwortet Vision, Roadmap und das ART Backlog mit den Features |
| ART | System Architect | verantwortet die technische Gesamtarchitektur und den architektonischen Vorlauf |
| ART | Business Owners | verantwortliche Führungskräfte, bewerten PI-Ziele und Ergebnisse |
| Portfolio | Epic Owner, Lean Portfolio Management | steuern große Vorhaben (Epics), Wertströme und Budgets |
Ein Agile Release Train (ART) besteht typischerweise aus fünf bis zwölf Teams mit zusammen etwa 50 bis 125 Personen. Die Teamkultur soll agil und selbstorganisiert sein; gleichzeitig gibt SAFe mehr Struktur und Führungsrollen vor als reine Team-Methoden.
Artefakte: von Epics bis Stories
SAFe arbeitet mit einer Hierarchie von Backlog-Einträgen: Große Vorhaben werden schrittweise in kleinere Einträge zerlegt, bis sie in eine Iteration eines Teams passen.
| Eintrag | Ebene (Backlog) | Umfang | verantwortet von |
|---|---|---|---|
| Epic | Portfolio Backlog | großes Vorhaben über mehrere PIs, mit Lean Business Case | Epic Owner |
| Capability | Solution Backlog (nur Large Solution) | Funktion, an der mehrere ARTs gemeinsam arbeiten | Solution Management |
| Feature | ART Backlog | Funktion, die ein ART in einem PI liefern kann | Product Management |
| Story | Team Backlog | kleiner Eintrag, den ein Team in einer Iteration umsetzt | Product Owner |
Weitere wichtige Artefakte sind:
PI-Ziele je Team und für den Train, mit Geschäftswert bewertet,
ART Planning Board (früher Program Board): zeigt, welches Feature in welcher Iteration fertig wird und welche Abhängigkeiten zwischen Teams bestehen,
Architectural Runway: technische Grundlagen, die künftige Features ermöglichen,
Roadmap und Vision.
Die Dokumentation ist mittel: deutlich leichter als im V-Modell, aber umfangreicher als in einem einzelnen Scrum-Team, weil Abhängigkeiten zwischen vielen Teams sichtbar sein müssen.
Qualität und Test: Built-in Quality und Delivery Pipeline
Qualität soll nicht nachträglich geprüft, sondern eingebaut werden (Built-in Quality, seit SAFe 6.0 Teil der Kernkompetenz Team and Technical Agility): Die Teams nutzen XP-Praktiken wie testgetriebene Entwicklung, Pair Programming und kontinuierliche Integration, es gibt eine gemeinsame Definition of Done, und das System wird mindestens in jeder Iteration integriert und in der System Demo als Ganzes geprüft. Die Continuous Delivery Pipeline beschreibt den Weg von der Idee bis zum Nutzen in vier Schritten: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand – hier fließen Ideen aus DevOps ein (siehe DevOps).
Stakeholder: Business Owners im Takt
Die Stakeholder sind über feste Termine eingebunden: Business Owners nehmen am PI Planning teil und bewerten die PI-Ziele, Kundschaft und Fachbereiche sehen in jeder System Demo das integrierte System, und im Inspect & Adapt werden Ergebnisse und Abweichungen gemeinsam ausgewertet. Product Management hält dazwischen den Kontakt zu Kundschaft und Markt.
Planung und Kontrolle: Flow-Kennzahlen und PI-Prognose
Geplant wird auf mehreren Horizonten: Portfolio-Vision und Roadmap (grob, ein bis drei Jahre), das nächste PI (verbindliche PI-Ziele) und die Iteration (Detail). Transparenz schaffen das ART Planning Board, die System Demos und die Backlogs. SAFe 6.0 nennt drei Bereiche von Kennzahlen: Wirkung (Outcomes, z. B. Geschäftsergebnisse), Fluss (Flow) und Kompetenz. Die sechs Flow-Kennzahlen sind Flow Velocity (fertige Einträge je Zeit), Flow Time (Durchlaufzeit), Flow Load (Arbeit in Arbeit), Flow Efficiency (Anteil aktiver Arbeit an der Durchlaufzeit), Flow Distribution (Verteilung auf Arten von Arbeit) und Flow Predictability (wie zuverlässig die geplanten PI-Ziele erreicht werden).
Skalierung und Anpassbarkeit: vier Konfigurationen
SAFe ist gerade für die Skalierung gemacht und bietet vier Konfigurationen:
Essential SAFe: Team- und ART-Ebene, der Kern für einen Release Train,
Large Solution SAFe: zusätzlich mehrere ARTs und Lieferanten für sehr große Systeme (Solution Train),
Portfolio SAFe: zusätzlich Strategie, Wertströme und Budgets (Lean Portfolio Management),
Full SAFe: alle Ebenen.
Organisationen wählen die kleinste Konfiguration, die ihre Situation abdeckt, und führen SAFe meist schrittweise ein (Implementation Roadmap). Leichtgewichtigere Alternativen sind LeSS (Large-Scale Scrum), Nexus und Scrum@Scale.
Häufig genutzte Techniken
WSJF (Weighted Shortest Job First): Priorisierung nach Kosten der Verzögerung geteilt durch Jobgröße,
Lean Business Case und Portfolio-Kanban für Epics,
Value Stream Mapping (Wertstromanalyse),
ROAM-Board zur Behandlung von Risiken im PI Planning (Resolved, Owned, Accepted, Mitigated),
XP- und DevOps-Praktiken auf Teamebene.
Risiken, Stärken und Grenzen
Häufige Stolpersteine: SAFe wird als schwergewichtige Struktur „von oben“ eingeführt, ohne dass sich Kultur und Führung ändern; klassische Planungsgewohnheiten werden nur umbenannt (PI als fester Wasserfall-Plan); die vielen Rollen und Ereignisse erzeugen Overhead; Teams verlieren Gestaltungsspielraum.
Typische Gegenmaßnahmen: Führungskräfte schulen und einbinden, mit einem Release Train und Essential SAFe beginnen, PI-Ziele als Prognose statt als Vertrag verstehen, Teams echte Entscheidungen überlassen, Inspect & Adapt ernsthaft nutzen.
Stärken: Ausrichtung vieler Teams auf gemeinsame Ziele, sichtbare Abhängigkeiten, regelmäßige Integration des Gesamtsystems, Anschluss an Strategie und Budget, umfangreiches Material und Schulungsangebot.
Grenzen: komplex und stark vorstrukturiert; Kritische Stimmen (etwa aus dem Umfeld von Scrum und LeSS) bemängeln, dass SAFe agile Werte durch Prozessvorgaben und Hierarchie verwässere; kommerzielles Framework mit Lizenz- und Zertifizierungsmodell; für einzelne Teams oder kleine Organisationen überdimensioniert.
Praxisbeispiele und Anwendungsfelder
SAFe wird eingesetzt, wo viele Teams an einem großen Produkt oder System arbeiten: Kernbankensysteme, Fahrzeugsoftware mit Hardware- und Zulieferanteilen, Telekommunikationsplattformen, große Behörden-IT. Beispiel: Ein Versicherer stellt sein Tarifsystem neu auf; acht Teams (Frontend, Tarifrechner, Schnittstellen, Datenmigration, Test-Automatisierung …) bilden einen Release Train, planen alle zehn Wochen gemeinsam im PI Planning und führen alle zwei Wochen das integrierte System vor. Typische Größen: Teams mit bis zu etwa zehn Personen, Release Trains mit 50 bis 125 Personen, Solution Trains mit mehreren Hundert.
Leitfragen
- Wozu dient SAFe, und was ist ein Agile Release Train?
SAFe überträgt agile Arbeit auf große Organisationen mit vielen Teams. Ein Agile Release Train fasst etwa fünf bis zwölf agile Teams (50 bis 125 Personen) zusammen, die im gemeinsamen Takt planen, integrieren und liefern, siehe Abschnitt „Herkunft“ und Abschnitt „Rollen“.
- Wie ist ein Planning Interval aufgebaut, und welche Ereignisse gehören dazu?
Ein PI dauert meist acht bis zwölf Wochen mit vier Iterationen und einer IP-Iteration. Es beginnt mit dem gemeinsamen PI Planning, jede Iteration endet mit einer System Demo des integrierten Systems, und das PI schließt mit Inspect & Adapt, siehe Abschnitt „Ablauf“.
- Welche Rollen gibt es auf der Ebene des Release Trains?
Release Train Engineer (moderiert und beseitigt teamübergreifende Hindernisse), Product Management (Vision, Roadmap, ART Backlog mit Features), System Architect (Gesamtarchitektur) und Business Owners (bewerten PI-Ziele); auf Teamebene gibt es Product Owner und Scrum Master/Team Coach, siehe Abschnitt „Rollen“.
- Wie hängen Epics, Features und Stories zusammen?
Epics sind große Vorhaben im Portfolio, sie werden (ggf. über Capabilities) in Features zerlegt, die ein Release Train in einem PI liefern kann; Features werden in Stories für die einzelnen Teams geteilt, siehe Abschnitt „Artefakte“.
- Welche Konfigurationen bietet SAFe?
Essential (Team und Release Train), Large Solution (mehrere Trains für sehr große Systeme), Portfolio (zusätzlich Strategie und Budgets) und Full (alle Ebenen), siehe Abschnitt „Skalierung und Anpassbarkeit“.
- Welche Kritik gibt es an SAFe, und welche Alternativen gibt es?
Kritische Stimmen bemängeln Komplexität, Overhead und viele Hierarchie- und Prozessvorgaben, die agile Werte verwässern können, sowie das kommerzielle Zertifizierungsmodell. Leichtgewichtigere Alternativen sind LeSS, Nexus und Scrum@Scale, siehe Abschnitt „Risiken, Stärken und Grenzen“.
Links und weitere Informationen
Vorgehensmodelle: klassisch und agil (Überblick und Vergleich)
Scrum, Kanban, Extreme Programming und DevOps
als Nachschlagewerk: SAFe Framework (Scaled Agile, Inc.)
zum Weiterlesen: Dean Leffingwell: Agile Software Requirements. Addison-Wesley, 2011
zum Vergleich: Large-Scale Scrum (LeSS) und Nexus Guide
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “SAFe: agile Arbeit über viele Teams skalieren” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/safe veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/vorgehensmodelle/vorgehensmodelle. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 30.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
