SAFe: Das Scaled Agile Framework erklärt

Das Scaled Agile Framework (SAFe) ist der am weitesten verbreitete Ansatz, um Agile in großen Unternehmen einzuführen. Wenn Ihre Organisation Hunderte von Entwicklern, Dutzende von Teams und komplexe Produktlinien hat, die sich nicht einfach in ein einzelnes Scrum-Setup integrieren lassen, bietet SAFe eine strukturierte Möglichkeit, all diese Einheiten zu koordinieren, ohne die Agile-Grundprinzipien aufzugeben, auf die Sie bereits setzen.

SAFe ist keine perfekte Lösung und hat echte Kritiker. Wer aber versteht, was SAFe tatsächlich ist und welche Probleme es lösen soll, trifft eine fundiertere Entscheidung darüber, ob es in die eigene Organisation passt.

Was ist SAFe (das Scaled Agile Framework)?

SAFe (Scaled Agile Framework) ist ein Satz organisatorischer Muster und Workflow-Muster zur Umsetzung von Agile-Praktiken im Unternehmensmaßstab. Entwickelt und gepflegt wird es von Scaled Agile, Inc. Das Framework kombiniert Ansätze aus Lean, Agile und Systemdenken, um Teams in der Größenordnung von Hunderten oder Tausenden von Mitarbeitern dabei zu helfen, Software und Produkte schneller, mit höherer Qualität und in besserer Abstimmung auf Geschäftsziele zu liefern.

Kleine Teams, die Scrum oder Kanban einsetzen, brauchen SAFe nicht. Wenn jedoch 50, 100 oder 500 Teams auf dieselbe Produktvision hinarbeiten müssen, wird Koordination zum eigentlichen Engpass. SAFe begegnet diesem Problem durch klar definierte Planungsebenen, gemeinsame Taktzyklen und spezifische Rollen, die Strategie und Umsetzung miteinander verbinden.

Wichtige Fakten

• SAFe wird von 35 % der Organisationen genutzt, die Agile skalieren, und ist damit das beliebteste Skalierungs-Framework (State of Agile Report, 2023).
• Organisationen, die SAFe einführen, berichten von einer 30- bis 75-prozentigen Verkürzung der Time-to-Market in Fallstudien von Scaled Agile, Inc. (Scaled Agile, Inc., 2022).
• Das Framework hat seit seiner Einführung im Jahr 2011 fünf Hauptversionen durchlaufen; SAFe 6.0 wurde 2023 veröffentlicht.

Die vier SAFe-Konfigurationen

SAFe ist keine Einheitslösung. Es gibt vier Konfigurationen, die jeweils auf unterschiedliche Unternehmensgrößen und Komplexitätsstufen ausgerichtet sind.

Die meisten Organisationen starten mit Essential SAFe. Die anderen Konfigurationen verursachen zusätzlichen Aufwand und sollten nur dann eingeführt werden, wenn die entsprechende Koordinationsebene tatsächlich benötigt wird.

Kernkonzepte: ARTs, PI Planning und die Ebenen

Der Agile Release Train (ART)

Der Agile Release Train ist das Rückgrat von SAFe. Ein ART ist ein dauerhaftes Team aus Agile-Teams (typischerweise 50 bis 125 Personen), das gemeinsam plant, sich verpflichtet und auf einer geteilten Mission liefert. Man kann ihn sich als eine virtuelle Organisation vorstellen, die über mehrere Produktzyklen zusammenbleibt.

Alle Teams in einem ART folgen demselben Iterationsrhythmus, in der Regel zweiwöchige Sprints. Sie nehmen an denselben Planungsveranstaltungen teil und arbeiten auf demselben Program-Increment-Zeitplan (PI). Dieser gemeinsame Takt ermöglicht es Dutzenden von Teams, synchron zu bleiben, ohne ständige Steuerung von oben.

Program Increment (PI) Planning

PI Planning ist der Herzschlag von SAFe. Alle 8 bis 12 Wochen kommen alle Teams eines ART für eine zweitägige Präsenzveranstaltung (oder ein virtuelles Äquivalent) zusammen, um das nächste Arbeitsinkrement zu planen. Teams analysieren den aktuellen Zustand des Produkts, prüfen die Roadmap und verpflichten sich auf spezifische Ziele für das bevorstehende PI.

Das Ergebnis sind PI-Objectives für jedes Team, ein konsolidiertes ART-Board, das Abhängigkeiten visualisiert, sowie ein Risikoregister. PI Planning wird oft als das „Herzstück" von SAFe bezeichnet, weil es echte Abstimmung zwischen Teams schafft, ohne dass ständige Managementeingriffe erforderlich sind. Es ist allerdings zeitintensiv, was einer der Gründe ist, warum Kritiker den Aufwand von SAFe hinterfragen.

Die Ebenen

SAFe organisiert Arbeit über drei (oder vier) Ebenen:

Teamebene. Einzelne Agile-Teams führen Sprints durch, pflegen Team-Backlogs und nehmen an standardmäßigen Agile Ceremonies wie Retrospektiven und Sprint-Reviews teil. Der Product Backlog auf dieser Ebene speist den Backlog auf Programmebene.

Programmebene. Hier agieren ARTs. Teams stimmen sich über PI Planning, das Program Board (zur Visualisierung teamübergreifender Abhängigkeiten) und einen gemeinsamen Programm-Backlog ab. Ein Release Train Engineer (RTE) begleitet diese Ebene.

Large-Solution-Ebene (bei Bedarf). Wenn mehrere ARTs gemeinsam an einem großen System arbeiten, koordiniert diese Ebene sie. Ein Solution Train Engineer und Solution Architects pflegen lösungsweite Backlogs und führen Solution-PI-Planning durch.

Portfolioebene. Hier verbindet sich Strategie mit Umsetzung. Business Leader definieren Investitionsthemen und Value Streams, legen Budgets mittels Lean Portfolio Management (LPM) fest und überwachen den Flow mithilfe eines Portfolio-Kanbans. Epics auf dieser Ebene werden in Features auf der Programmebene heruntergebrochen und dann in User Stories auf Teamebene.

SAFe-Rollen

SAFe definiert ein umfangreiches Set an Rollen auf jeder Ebene. Die wichtigsten im Überblick.

Der RTE wird oft als „Super Scrum Master" für den Zug beschrieben. Es ist eine Vollzeitstelle, und die Qualität des RTE bestimmt maßgeblich, wie gut der ART tatsächlich funktioniert.

Vorteile von SAFe

Abstimmung im großen Maßstab. PI Planning schafft einen gemeinsamen Plan, auf den alle Beteiligten, von Entwicklern bis zu Führungskräften, Bezug nehmen können. Teams wissen, wie ihre Arbeit mit der übergeordneten Produktvision zusammenhängt. Diese Art von Ausrichtung ist in großen Organisationen selten und wertvoll.

Vorhersehbare Lieferung. Da alle Teams auf demselben PI-Takt arbeiten, kann das Management Lieferzeitpunkte mit vertretbarer Genauigkeit prognostizieren. Was aus jedem PI herauskommt, ist bereits vor dem Start des PI in etwa bekannt.

Kürzere Feedback-Schleifen. SAFe fordert von Teams, alle zwei Wochen funktionierende Software zu liefern, mit System-Demos am Ende jedes PI. Das ist eine deutlich engere Feedback-Schleife als der klassische Waterfall-Releasezyklus, den viele Unternehmen noch betreiben.

Eingebaute Business Agility. Das Lean Portfolio Management von Portfolio SAFe gibt Führungskräften die Möglichkeit, Investitionen zwischen Value Streams umzuschichten, ohne auf den nächsten jährlichen Budgetzyklus warten zu müssen. Es ist keine echte kontinuierliche Finanzierung, aber deutlich reaktionsfähiger als typische Unternehmensplanung.

Community und Tooling. SAFe verfügt über eine große zertifizierte Praktiker-Community und wird von Plattformen wie Jira Align, Rally und Planview gut unterstützt. Dieses Ökosystem kann die Einführung beschleunigen.

Kritik und Grenzen

SAFe hat echte Kritiker, und ihre Einwände verdienen ernsthafte Beachtung, bevor man sich festlegt.

Hoher Aufwand. SAFe führt viele Rollen, Artefakte und Ceremonies zusätzlich zu dem ein, was Teams bereits leisten. Für Organisationen, die mit „Agile" vor allem „einfach und anpassungsfähig" verbinden, kann SAFe das Gegenteil davon wirken.

Von oben nach unten konzipiert. Ein anhaltender Kritikpunkt ist, dass SAFe traditionelle Managementhierarchien unter einem Agile-Label reproduziert. Business Owners genehmigen PI-Objectives. Budgets fließen von der Portfolioebene nach unten. Teams planen entlang einer Roadmap, die Stakeholder aus dem Business weitgehend kontrollieren. Das ist weit entfernt von den selbstorganisierenden Teams im Kern des Agile Manifesto.

„SAFe ist nicht agil." Eine lautstarke Gruppe von Agile-Coaches und Vordenken argumentiert, dass SAFes Starrheit Agile-Werten widerspricht. Dave Thomas (einer der ursprünglichen Unterzeichner des Manifesto) und andere haben es dafür kritisiert, Prozesse über Menschen zu institutionalisieren. Ron Jeffries hat es als „Dark Scrum mit zusätzlichen Schritten" bezeichnet. Das sind starke Worte, aber die zugrunde liegende Sorge ist berechtigt: Organisationen können die Ceremonies von SAFe übernehmen und dabei die Denkweise verlieren, die Agile zum Funktionieren bringt.

Velocity in Agile kann in die Irre führen. Wenn SAFe-Teams die Velocity auf PI-Ebene messen, ohne zu prüfen, ob diese Zahlen in echten Nutzerwert übersetzt werden, optimieren sie für Output statt für Ergebnisse. SAFe verhindert das nicht, und der Druck, sich auf PI-Objectives festzulegen, kann die Situation verschärfen.

Zertifizierungskultur. Das SAFe-Zertifizierungsökosystem (SAFe Agilist, RTE, POPM usw.) schafft ein Geschäftsmodell, das manche Kritiker für nicht vereinbar mit dem Geist von Agile halten. Zertifikate können zur reinen Formsache werden statt echter Kompetenz zu belegen.

Nichts davon bedeutet, dass SAFe für Ihre Organisation falsch ist. Aber mit offenen Augen einzusteigen hilft Ihnen zu vermeiden, dass Sie die Bürokratie einführen, ohne ihren Nutzen zu ernten.

SAFe implementieren

Scaled Agile, Inc. veröffentlicht eine Implementation Roadmap. Hier ist eine verständliche Zusammenfassung.

Schritt 1: Das Führungsteam schulen

SAFe funktioniert nicht, wenn die Führungskräfte nicht überzeugt und geschult sind. Beginnen Sie mit einem zweitägigen „Leading SAFe"-Kurs für Führungskräfte, Direktoren und leitende Manager. Wenn Führungskräfte weiterhin Waterfall-Portfolioplanung betreiben, während Teams versuchen, SAFe zu leben, wird das Framework an den Nahtstellen scheitern. Die Ausrichtung der Führung ist nicht verhandelbar.

Schritt 2: Value Streams und ARTs identifizieren

Kartieren Sie Ihre Organisation anhand der Arbeit, die sie für Kunden erbringt, nicht anhand Ihres Organigramms. Ein Value Stream ist die Abfolge von Schritten, die ein Produkt oder eine Dienstleistung hervorbringt, die Kunden schätzen. Jeder Value Stream bildet die Grenze eines ART. Definieren Sie Ihren ersten ART, bevor Sie den zweiten definieren: Es ist einfacher, zu lernen, anzupassen und dann zu erweitern, als fünf ARTs gleichzeitig zu starten.

Schritt 3: Den Umsetzungsplan erstellen

Das bedeutet: PI-Länge festlegen (8 oder 12 Wochen), das erste PI-Planning-Event planen, die Teams schulen, die den ART bilden werden, und die Rollen besetzen (RTE, Product Management, System Architect). Nicht jede Rolle muss vom ersten Tag an perfekt besetzt sein, aber die Kernrollen müssen von Personen übernommen werden, die das Framework verstehen.

Schritt 4: Teams schulen und den ART starten

Führen Sie ein zweitägiges ART-Launch-Event durch, das SAFe-for-Teams-Training mit dem ersten PI Planning verbindet. So werden alle Teammitglieder eingeführt und der erste echte PI-Plan entsteht. Rechnen Sie damit, dass es unruhig wird. Erste PI-Planning-Events verlaufen selten reibungslos. Das ist zu erwarten und in Ordnung.

Schritt 5: Die Umsetzung begleiten

Während der ersten PIs sollte kontinuierlich gecoacht werden. RTEs und Scrum Master müssen Teams dabei helfen, den Takt zu verinnerlichen. Typische Schwachstellen: Teams, die Iterations-Reviews überspringen, PI-Objectives, die zu unspezifisch sind, um bewertet zu werden, und eine Abhängigkeitsverfolgung auf dem Program Board, die niemand aktuell hält.

Schritt 6: Ausweiten und verbessern

Nach zwei bis drei PIs analysieren Sie, was funktioniert und was nicht. Führen Sie am Ende jedes PI einen gründlichen Inspect-and-Adapt-Workshop (I&A) durch, um umsetzbare Verbesserungen zu erarbeiten. Weiten Sie erst auf einen zweiten ART oder auf Portfolio SAFe aus, wenn der erste ART stabil läuft. Kaputte Prozesse zu skalieren vergrößert nur die Probleme.

SAFe im Vergleich zu anderen Skalierungsansätzen

Wenn Sie Scrumban für einzelne Teams in Betracht ziehen oder Agile vs. Scrum vergleichen, bevor Sie sich für einen Skalierungsansatz entscheiden, lesen Sie diese Artikel zuerst. Die Praxis auf Teamebene, die Sie wählen, beeinflusst, wie gut jedes Skalierungs-Framework darauf aufbauen kann.

Häufig gestellte Fragen

Ist SAFe noch Agile?

Das hängt davon ab, wie Sie es implementieren. SAFe enthält Agile-Prinzipien und nutzt Agile-Ceremonies, aber seine strukturierte Hierarchie und die Top-down-Planungszyklen stehen einigen Kernwerten von Agile entgegen. Gut umgesetzt kann SAFe wirklich anpassungsfähige Organisationen hervorbringen. Schlecht umgesetzt erzeugt es den Anschein von Agilität, während alle alten Kontroll- und Steuerungsmechanismen erhalten bleiben.

Wie lang ist ein Program Increment (PI)?

Ein PI dauert in der Regel 8 bis 12 Wochen. Die meisten Organisationen nutzen 10-wöchige PIs, die aus fünf zweiwöchigen Iterationen bestehen. Die letzte Iteration ist üblicherweise eine Innovation-and-Planning-Iteration (IP), die für Abschlussarbeiten, Stabilisierung und die Planung des nächsten PI genutzt wird.

Braucht man eine SAFe-Zertifizierung, um es einzuführen?

Nein. Zertifizierungen helfen Teams, das Framework schneller zu erlernen, und ein RTE-Zertifikat verleiht dem RTE Glaubwürdigkeit gegenüber den Teams, die er begleitet. Organisationen haben SAFe aber auch mit minimaler formaler Zertifizierung erfolgreich eingeführt, indem sie in internes Coaching und praktische Erfahrung investiert haben. Das Zertifizierungsökosystem ist nützlich, aber kein Garant für Erfolg.

Wie viele Teams bilden einen Agile Release Train?

Ein ART hat typischerweise 5 bis 12 Teams mit je 5 bis 9 Mitgliedern. Das ergibt eine ART-Größe von 50 bis 125 Personen. Wenn die Größe 125 überschreitet, sollte man den ART in zwei aufteilen oder zur Large-Solution-Konfiguration wechseln.

Was ist der Unterschied zwischen einem Epic und einem Feature in SAFe?

Ein Epic ist eine große geschäftliche oder technische Initiative, die auf Portfolio- oder Large-Solution-Ebene definiert wird. Features sind kleinere Liefergegenstände auf Programmebene, die Teile eines Epics umsetzen. Teams zerlegen Features dann in User Stories in ihren Team-Backlogs. Die Epic-Feature-Story-Hierarchie ist der Weg, auf dem Arbeit von der Strategie bis zur täglichen Umsetzung fließt.

Was SAFe richtig macht und wie es weitergeht

SAFe ist nicht für jeden geeignet. Für große Organisationen, die wirklich mit Koordinationsproblemen, nicht abgestimmten Roadmaps und langsamen Lieferprozessen kämpfen, bietet es jedoch einen konkreten Ausgangspunkt. Der größte Wert des Frameworks liegt nicht in den Ceremonies selbst, sondern in der gemeinsamen Sprache und dem gemeinsamen Takt, den es für Teams schafft, die bisher keinen gemeinsamen Rhythmus hatten.

Fangen Sie klein an, schulen Sie ehrlich, und führen Sie echte Inspect-and-Adapt-Sessions durch. Die Organisationen, die den größten Nutzen aus SAFe ziehen, behandeln es als Ausgangskonfiguration, nicht als dauerhaftes Ziel.

Wenn Sie noch zwischen verschiedenen Lieferansätzen abwägen, bietet Extreme Programming eine stärker technikorientierte Alternative, die es sich neben SAFe zu prüfen lohnt.

Weiterführende Artikel

• Was ist Agile Methodik?
• Was ist Scrum?
• Agile vs. Scrum
• Sprint Planning
• Agile Ceremonies
• Product Backlog
• Das Agile Manifesto
• Scrumban