Agilität

SAFe und skalierte Agilität: wann und wie Sie von Scrum zum Scaled Agile Framework wechseln

Von Codevista InnovationsVeröffentlicht am 12. Oktober 2026Aktualisiert am 15. Oktober 20269 Min. Lesezeit

SAFe (Scaled Agile Framework) lohnt sich, wenn mehrere agile Teams gemeinsam eine Lösung liefern und Abhängigkeiten, widersprüchliche Prioritäten und späte Integration zunichtemachen, was jedes Team mit Scrum gewinnt. Das Framework bringt eine Struktur, den Agile Release Train, ein gemeinsames Planungsereignis, das PI Planning, und ein Lean-Portfoliomanagement mit, um den Preis zusätzlicher Rollen und Events. Prüfen Sie vor der Einführung, ob Ihr Problem tatsächlich in der Abstimmung zwischen den Teams liegt und ob die Geschäftsleitung bereit ist, sich selbst einzubringen.

Woran erkennen Sie, dass Scrum nicht mehr reicht?

Scrum ist für ein kleines Team gedacht, das allein ein nutzbares Inkrement liefern kann. Solange ein Produkt in ein oder zwei Teams passt, löst konsequenteres Scrum oder ein Wechsel zu Kanban meist das Wesentliche (siehe unseren Vergleich Scrum oder Kanban). Die Schwierigkeiten ändern ihren Charakter, sobald mehrere Teams an derselben Lösung arbeiten:

• Kaskadierende Abhängigkeiten: Ein Team wartet auf eine API, eine Umgebung oder eine Freigabe eines anderen, und der Sprint endet ohne nutzbares Inkrement.
• Nicht abgestimmte Prioritäten: Jeder Product Owner optimiert sein eigenes Backlog, niemand entscheidet zwischen den Teams, und der Fachbereich erhält Funktionsfragmente, die für sich genommen nutzlos sind.
• Mühsame Integration: Jedes Team erklärt sich für sich „fertig“, und das Zusammenführen am Quartalsende gleicht aufs Haar der früheren Integrationsphase im V-Modell.
• Keine Transparenz für die Geschäftsleitung, die schließlich detaillierte Sechsmonatspläne verlangt, im Widerspruch zu den Sprints.

Ein einfacher Test: Lesen Sie die Hindernisse nach, die in den letzten Retrospektiven genannt wurden. Betreffen sie vor allem die interne Arbeitsweise der einzelnen Teams, liegt das Problem nicht in der Größe. Verweisen sie immer wieder auf ein anderes Team, eine fehlende Entscheidung oder eine verspätete Integration, ist die Frage nach skalierter Agilität berechtigt.

Was SAFe hinzufügt: Agile Release Train, PI Planning und Portfolio

Das Scaled Agile Framework ersetzt Scrum oder Kanban auf Teamebene nicht, sondern organisiert die Teams um einen gemeinsamen Wertstrom. Die offizielle Referenz, maßgeblich für die Terminologie und von Version zu Version weiterentwickelt, ist auf scaledagileframework.com veröffentlicht.

Der Agile Release Train (ART)

Ein ART ist ein dauerhaft bestehendes Team aus agilen Teams mit derselben Mission, demselben ART Backlog und demselben Takt. Er bleibt bewusst begrenzt, laut Referenz in der Größenordnung von 50 bis 125 Personen, damit alle im selben Raum planen können. Der Release Train Engineer (RTE) moderiert ihn, das Product Management priorisiert die Features, der System Architect verantwortet die technische Vision, und die Business Owners vertreten die fachlichen Interessen und geben die Ziele frei.

Das PI Planning

Ein PI (Planning Interval, früher Program Increment) umfasst mehrere Iterationen, gefolgt von einer Innovations- und Planungsiteration (IP Iteration). Zu Beginn jedes PI kommen alle Teams des Trains zum PI Planning zusammen, in der Regel über zwei Tage: Sie zerlegen die Features, machen die Abhängigkeiten auf dem ART Planning Board sichtbar und verpflichten sich auf PI Objectives. Während des PI zeigt die System Demo das integrierte Inkrement des gesamten Trains; abgeschlossen wird das PI mit einem Inspect & Adapt.

Die Portfolioebene

In der Konfiguration Portfolio SAFe finanziert das Lean Portfolio Management Wertströme statt einzelner Projekte, und Epics durchlaufen ein Portfolio-Kanban, bevor sie freigegeben werden. Hier entscheidet sich für eine Geschäftsleitung oft die eigentliche Veränderung, denn sie betrifft Budget und Governance, nicht nur die Arbeitsweise der Teams.

Was kostet SAFe an Events und Organisation?

Die Kosten von SAFe beschränken sich nicht auf eine Schulungsrechnung. Sie bemessen sich vor allem in Zeit und Aufmerksamkeit:

• Neue Rollen (RTE, Product Management, System Architect), besetzt mit Personen, die tatsächlich verfügbar sind, statt sie einer ohnehin vollen Stelle aufzubürden.
• Zusätzliche Events: PI Planning, System Demo, Inspect & Adapt, regelmäßige Abstimmungen zwischen den Teams, vorgelagerte Verfeinerung der Features.
• Ein gemeinsames Vokabular, das die gesamte Organisation übernehmen muss, also Schulung für Teams, Führungskräfte und Geschäftsleitung.
• Ein proprietäres Framework: SAFe ist eine Marke von Scaled Agile, Inc., die die offiziellen Zertifizierungen vergibt; das schlägt sich im Budget für Schulung und Zertifizierung nieder.
• Bürokratierisiko, wenn das Framework mechanisch, Artefakt für Artefakt, angewendet wird, ohne zu fragen, was jedes einzelne bringt.

Diese Kosten rechtfertigen sich, wenn sie bereits teure informelle Abstimmungen ersetzen: Krisensitzungen, Entscheidungen per Eskalation, verlorene Wochen in der Integration. Sie rechtfertigen sich nicht für zwei Teams, die sich einfach ein Backlog und ein Review teilen könnten.

SAFe, LeSS, Scrum@Scale oder Kanban: welche Alternativen gibt es?

SAFe ist das am umfassendsten ausgestattete und am stärksten vorschreibende Framework, aber nicht das einzige. Die Alternativen sind nicht grundsätzlich besser oder schlechter; sie setzen andere Schwerpunkte:

• LeSS (Large-Scale Scrum): ein einziger Product Owner und ein einziges Product Backlog für mehrere Teams, sehr wenige zusätzliche Rollen. Anspruchsvoll in Bezug auf technische Reife und Umbau der Organisation.
• Scrum@Scale: eine modulare Erweiterung von Scrum, die die Organisation über miteinander verbundene Teamnetzwerke wachsen lässt.
• Nexus: das Framework von Scrum.org für einige Scrum-Teams, die am selben Produkt arbeiten, mit einem eigenen Integrationsteam.
• Ein gut gepflegtes Portfolio-Kanban: alle laufenden Initiativen sichtbar machen, die parallele Arbeit auf Ebene der Geschäftsleitung begrenzen und in regelmäßigen Abständen priorisieren. Oft der günstigste erste Schritt, der zudem jedes spätere Framework vorbereitet.

SAFe eignet sich vor allem für große Organisationseinheiten, die explizite Rollen, eine Portfolio-Governance und eine gemeinsame Sprache mit der Geschäftsleitung brauchen. Für ein Produkt, das drei oder vier Teams tragen, ist ein schlankeres Framework in der Regel angemessener.

Warum scheitert eine SAFe-Einführung?

Die Fehlschläge ähneln sich von Organisation zu Organisation:

• Nach Abteilungen statt nach Wertströmen organisierte Trains: Sie reproduzieren die Silos unter neuem Namen.
• Teams, die Scrum nicht beherrschen: Ohne stabile Iterationen und gemeinsame Definition of Done verstärkt die Skalierung das Chaos.
• Ein verordnetes PI Planning: Die Geschäftsleitung kommt mit festgelegtem Umfang und Termin, ohne die von den Teams genannte Kapazität zu berücksichtigen.
• Mitten im PI geänderte Prioritäten am Product Management vorbei, wodurch die PI Objectives ihren Sinn verlieren.
• Schwache technische Praktiken: Ohne Continuous Integration und automatisierte Tests zeigt die System Demo Bildschirme, aber kein integriertes System.
• Ein Framework fürs Image, ohne Messung des Flusses oder der fachlichen Ergebnisse.

Keine dieser Ursachen liegt am Framework selbst: Sie sind organisatorischer Natur. Deshalb zählt die Vorbereitung mehr als die Wahl zwischen SAFe und seinen Konkurrenten.

Wie bereiten Sie ein erstes PI Planning vor?

Ein erstes PI Planning wird über mehrere Wochen vorbereitet. Die wesentlichen Schritte:

1. Den Wertstrom identifizieren und die Teams, die dazu beitragen, einschließlich unverzichtbarer Unterstützungsfunktionen (Sicherheit, Betrieb, Compliance).
2. Schlüsselrollen benennen und schulen: RTE, Product Management, System Architect, Business Owners sowie Scrum Master und Product Owner der Teams.
3. Das ART Backlog aufbauen: priorisierte Features mit Akzeptanzkriterien und Hypothese zum fachlichen Nutzen. Regulatorische Anforderungen, etwa der Schutz personenbezogener Daten nach dem Gesetz 09-08 (loi 09-08, das marokkanische Datenschutzgesetz), gehören von Anfang an hinein, nicht erst ans Ende des PI.
4. Die Vision vorbereiten, die die Geschäftsleitung zur Eröffnung präsentiert: fachlicher Kontext, Ziele, Rahmenbedingungen, bekannte Meilensteine.
5. Die Kapazität jedes Teams berechnen, unter Berücksichtigung von Urlaub, Feiertagen und dem für Wartung reservierten Anteil.
6. Die Logistik organisieren: Raum oder Kollaborationstool, ART Planning Board, getaktete Agenda, Entscheider von Anfang bis Ende anwesend.

Während des Events

Der typische Ablauf wechselt zwischen Plenumsphasen und Teamarbeit: Vorstellung des fachlichen Kontexts, der Produktvision und der Architekturvision, danach Workshops, in denen jedes Team seinen Iterationsplan erstellt. Ein Review der vorläufigen Pläne und eine Problemlösungsrunde mit der Geschäftsleitung ermöglichen es, den Umfang anzupassen. Am zweiten Tag stellen die Teams ihre endgültigen Pläne vor, die Risiken werden nach der ROAM-Methode (Resolved, Owned, Accepted, Mitigated) behandelt, und ein Vertrauensvotum schließt die Übung ab. Ein schwaches Votum ist kein Misserfolg, sondern das Signal, vor einer Zusage neu zu planen.

Sind die Teams auf mehrere Standorte verteilt, in Casablanca, anderswo in Marokko oder im Ausland, funktioniert ein gut ausgestattetes hybrides Format, sofern die Business Owners während der zwei Tage für Entscheidungen erreichbar bleiben.

Was die Geschäftsleitung für den Erfolg von SAFe einbringen muss

SAFe lässt sich nicht an die IT-Abteilung delegieren. Die Geschäftsleitung muss:

• Teilnehmen: Die Business Owners sind beim PI Planning, bei der System Demo und beim Inspect & Adapt dabei und weisen den PI Objectives einen fachlichen Wert zu.
• Wertströme finanzieren statt Projekte, was eine Überarbeitung des Budgetzyklus voraussetzt.
• Das PI schützen: keine ohne Abwägung eingeschobenen Eilthemen, wenige parallel laufende Initiativen.
• Die Transformation tragen: ein Steuerungsteam benennen, das die Referenz Lean-Agile Center of Excellence (LACE) nennt, und ihm Zeit und Entscheidungsbefugnis geben.
• Sich in agiler Führung schulen lassen und akzeptieren, dass mehrere PIs nötig sind, bis ein Train seinen Rhythmus findet.

HR, Finanzen oder Marketing sind betroffen, sobald die Wertströme sie durchqueren (siehe Agilität jenseits der IT). Für ein KMU passt ein schlankerer Ansatz oft besser zu einer schrittweisen digitalen Transformation.

Codevista Innovations bietet eine SAFe-Schulung für Organisationen an, die über ein einzelnes Team hinausgewachsen sind, sowie eine Scrum-Schulung, um die Grundlagen zu festigen, in Präsenz überall in Marokko, hybrid oder remote. Unser Qualifizierungsdossier bei der marokkanischen Berufsbildungsbehörde OFPPT ist in Arbeit; bis dahin sind diese Programme noch nicht über deren Contrats Spéciaux de Formation (CSF) förderfähig. Um zu klären, ob SAFe zu Ihrer Situation passt, kontaktieren Sie unser Team.

Häufige Fragen

Wie viele Teams braucht es, damit sich SAFe lohnt?

Eine magische Schwelle gibt es nicht. Ein Agile Release Train vereint mehrere agile Teams, die gemeinsam eine Lösung liefern, laut Referenz in der Größenordnung von 50 bis 125 Personen. Bei zwei oder drei Teams genügen oft ein gemeinsames Backlog, gemeinsame Reviews oder ein schlankes Framework wie Nexus oder LeSS. Entscheidend sind der Grad der Abhängigkeit zwischen den Teams und der Bedarf an einer gemeinsamen, für die Geschäftsleitung sichtbaren Planung.

Was ist der Unterschied zwischen PI Planning und Sprint Planning?

Das Sprint Planning betrifft ein einzelnes Team und eine Iteration. Das PI Planning bringt alle Teams eines Agile Release Train mit Product Management, Architektur und Business Owners zusammen, um gemeinsam ein Planning Interval aus mehreren Iterationen zu planen. Es macht Abhängigkeiten sichtbar und mündet in PI Objectives. Innerhalb des PI behält jedes Team anschließend seine eigene Iterationsplanung.

Muss man Scrum beherrschen, bevor man zu SAFe wechselt?

Ja, das ist dringend zu empfehlen. SAFe baut auf Teams, die in jeder Iteration ein funktionsfähiges Inkrement liefern können, mit klaren Rollen und einer gemeinsamen Definition of Done. Haben die Teams schon mit den Grundlagen Mühe, verstärkt die Skalierung die Probleme, statt sie zu lösen. Scrum oder Kanban auf Teamebene zu festigen, ist daher oft der erste Schritt.

Kann eine SAFe-Schulung in Marokko über die OFPPT gefördert werden?

Das Instrument gibt es: Über die Contrats Spéciaux de Formation (CSF) der OFPPT kann ein Unternehmen einen Teil seiner Schulungskosten zurückerhalten. Das Qualifizierungsdossier von Codevista Innovations ist in Arbeit; bis dahin sind seine Programme, darunter die SAFe-Schulung, nicht darüber förderfähig. Zugangsvoraussetzungen und Verfahren legt die OFPPT fest: Prüfen Sie sie direkt bei der Behörde, bevor Sie den Antrag stellen. Unser Artikel zur CSF-Förderung erklärt das Prinzip.