SAFe Rollen & Ebenen einfach erklärt – Scaled Agile Framework (SAFe) gilt heute als eines der bekanntesten Rahmenwerke, um agile Methoden in großen Unternehmen zu skalieren. Viele Teams kennen Scrum bereits gut, aber auf Organisationsebene tauchen schnell Fragen auf: Welche Ebenen gibt es im SAFe? Welche Rollen sind wirklich wichtig – und wie greifen sie ineinander?
In diesem Artikel schauen wir uns die Ebenen und Rollen in SAFe Schritt für Schritt an, verständlich und gleichzeitig fachlich sauber. So erkennst du, wo dein eigener Platz im SAFe-Zusammenhang liegt und wie du mit anderen Rollen optimal zusammenarbeitest.

1. Kurzer Überblick: Was ist SAFe überhaupt?
SAFe ist ein Framework für skalierte Agilität, das mehrere agile Teams, ganze Wertströme und sogar das Portfolio-Management miteinander verbindet.
Statt nur einzelne Scrum-Teams zu optimieren, schafft SAFe einen gemeinsamen Ordnungsrahmen:
- Es beschreibt Ebenen, auf denen gearbeitet wird (z. B. Team, Programm, Portfolio).
- Es definiert Rollen, die Verantwortung übernehmen.
- Es gibt Artefakte vor (z. B. Backlogs, Epics, Features, User Stories).
- Es bietet Events, in denen Planung, Abstimmung und Inspect & Adapt stattfinden.
Gerade in größeren Organisationen entstehen sonst schnell Silos, Abhängigkeiten und Priorisierungskonflikte. SAFe adressiert genau diese Probleme, ohne die Grundideen agiler Arbeitsweise aufzugeben.
2. Die Ebenen im SAFe-Framework
SAFe unterscheidet je nach Konfiguration bis zu vier Ebenen. In der Praxis begegnen dir meistens:
- Team-Ebene
- Program-Ebene (Agile Release Train)
- Large-Solution-Ebene (für sehr große Systeme)
- Portfolio-Ebene
Schauen wir uns diese Ebenen nacheinander an.
2.1 Team-Ebene – dort, wo die eigentliche Arbeit passiert
Auf der Team-Ebene arbeiten agile Teams, häufig nach Scrum oder Kanban.
Typische Merkmale:
- Teamgröße: ca. 5–11 Personen
- Ziel: In kurzen Iterationen (Sprints) funktionierende, getestete Inkremente liefern
- Backlog-Ebene: User Stories
- Zeithorizont: 2 Wochen Iterationen (häufig, aber nicht zwingend)
Die Team-Ebene fokussiert sich stark auf die operative Umsetzung, während höhere Ebenen für Ausrichtung und Koordination sorgen.
2.2 Program-Ebene – der Agile Release Train (ART)
Mehrere agile Teams, die gemeinsam an einem Produkt oder System arbeiten, formen im SAFe einen Agile Release Train (ART).
Charakteristika eines ART:
- 50–125 Personen, verteilt auf mehrere Teams
- Gemeinsame Mission und Vision
- Gemeinsame Program Backlog mit Features
- Fester Program Increment (PI)-Rhythmus, meist 8–12 Wochen
- Gemeinsame Events wie PI Planning und System Demos
Der ART sorgt dafür, dass alle Teams auf ein gemeinsames Ziel einzahlen, sodass nicht jedes Team seine eigene Agenda verfolgt.
2.3 Large-Solution-Ebene – wenn ein ART nicht mehr reicht
In sehr großen Unternehmen oder bei sehr komplexen Systemen arbeiten oft mehrere ARTs zusammen. Hier kommt die Large-Solution-Ebene ins Spiel.
Sie koordiniert:
- Mehrere Agile Release Trains
- Ggf. zusätzliche Lieferanten (Suppliers)
- Systemweite Architekturentscheidungen
- Abhängigkeiten und Integration großer Lösungen
Nicht jede Organisation benötigt diese Ebene, aber bei sicherheitskritischen oder stark regulierten Systemen wird sie schnell unverzichtbar.
2.4 Portfolio-Ebene – Ausrichtung auf Unternehmensstrategie
Die Portfolio-Ebene verbindet SAFe mit der strategischen Ausrichtung des Unternehmens.
Hier geht es um:
- Strategische Epics (geschäftlich & technisch)
- Budgetierung und Lean Portfolio Management
- Wertströme (Value Streams) auf Unternehmensebene
- Governance, Compliance und strategische Roadmaps
Dadurch lässt sich sicherstellen, dass die Arbeit in den Teams direkt mit Unternehmenszielen verknüpft bleibt und nicht an der Strategie vorbeiläuft.
3. Wichtige SAFe-Rollen auf einen Blick
SAFe definiert eine Reihe klarer Rollen, sodass Verantwortung und Entscheidungsbefugnisse transparent bleiben. Diese Rollen verteilen sich über die Ebenen.
Wir betrachten die wichtigsten:
- Rollen auf Team-Ebene
- Rollen auf Program-/ART-Ebene
- Rollen auf Large-Solution-Ebene
- Rollen auf Portfolio-Ebene
4. Rollen auf der Team-Ebene
Auf der Team-Ebene orientiert sich SAFe stark an Scrum, ergänzt dies aber um einige SAFe-spezifische Aspekte.
4.1 Product Owner (PO)
Der Product Owner verantwortet den Wert der Arbeit, die das Team liefert.
Seine Kernaufgaben:
- Priorisierung des Team Backlogs
- Klärung von Anforderungen mit Stakeholdern und dem Product Manager
- Formulierung und Pflege von User Stories
- Teilnahme an:
- Iteration Planning
- Backlog Refinement
- Review und Retrospektive
Der PO agiert als Übersetzer zwischen Business und Team, sodass Anforderungen klar und verständlich in das Team einfließen.
4.2 Scrum Master / Team Coach
Der Scrum Master (in neueren SAFe-Versionen oft als Team Coach bezeichnet) sorgt dafür, dass das Team effektiv und nach agilen Prinzipien arbeitet.
Seine Aufgaben:
- Moderation von Team-Events
- Beseitigung von Hindernissen (Impediments)
- Coaching des Teams in agilen Praktiken
- Unterstützung bei der Zusammenarbeit mit anderen Teams und Rollen
Er ist kein Projektmanager im klassischen Sinn, sondern ein Servant Leader, der das Team stärkt und schützt.
4.3 Agile Team-Mitglieder
Die Teammitglieder (Developers, Engineers, Tester etc.) tragen gemeinsam die Verantwortung für die Lieferung eines qualitativ hochwertigen Inkrements.
Typische Eigenschaften:
- Cross-funktional: Entwicklung, Test, ggf. UX, DevOps usw.
- Enger Austausch mit PO und Scrum Master
- Fokus auf technische Exzellenz und kontinuierliche Verbesserung
In SAFe sprechen viele Praktiker lieber von „Agile Teams“ statt von getrennten Funktionen, weil der Fokus konsequent auf dem gemeinsamen Ergebnis liegt.
5. Rollen auf der Program-/ART-Ebene
Auf der Program-Ebene dreht sich im SAFe alles um den Agile Release Train.
5.1 Release Train Engineer (RTE)
Der Release Train Engineer ist so etwas wie der „Scrum Master des ganzen Trains“.
Seine Verantwortung:
- Moderation des PI Plannings
- Koordination der übergreifenden Events (Scrum of Scrums, ART Sync, System Demo)
- Unterstützung der Teams bei der Beseitigung von Abhängigkeiten
- Förderung von Transparenz und Fluss über alle Teams hinweg
Damit hält der RTE den Train zusammen, ohne selbst hierarchische Macht auszuüben.
5.2 Product Manager
Während der PO für das Team-Backlog verantwortlich ist, übernimmt der Product Manager das Program Backlog auf ART-Ebene.
Aufgaben des Product Managers:
- Definition und Priorisierung von Features
- Abstimmung mit Business Ownern, Kunden und Markt
- Pflege der ART-Roadmap
- Zusammenarbeit mit mehreren Product Ownern
Der Product Manager sorgt dafür, dass der gesamte ART auf die richtigen geschäftlichen Ergebnisse hinarbeitet.
5.3 System Architect / Solution Architect
Der System Architect (oder Solution Architect) verantwortet die technische und architektonische Ausrichtung des ART.
Typische Aufgaben:
- Definition von Architectural Runway und Leitplanken
- Harmonisierung von Technologien und Schnittstellen
- Unterstützung bei nicht-funktionalen Anforderungen (Security, Performance, Skalierbarkeit)
- enge Zusammenarbeit mit Teams, RTE und Product Management
Dadurch entsteht eine klare technische Vision, die trotzdem genügend Freiraum für Team-Autonomie lässt.
5.4 Business Owner
Business Owner vertreten die geschäftliche Verantwortung für den ART.
Sie:
- legen gemeinsam mit dem ART Ziele und Metriken fest
- treffen verbindliche Geschäftsentscheidungen
- unterstützen Priorisierungen im Program Backlog
- nehmen an wichtigen Events wie PI Planning und Inspect & Adapt teil
Business Owner sind damit Schlüsselakteure für die Verbindung von Business und Delivery.
6. Rollen auf der Large-Solution-Ebene
Wenn mehrere ARTs gemeinsam eine sehr große Lösung liefern, treten zusätzliche Rollen hinzu.
6.1 Solution Train Engineer (STE)
Der Solution Train Engineer ist vergleichbar mit einem RTE auf einer höheren Ebene.
Er koordiniert:
- Mehrere Agile Release Trains und ggf. Supplier
- Übergreifende Events auf Solution-Ebene
- Abhängigkeiten zwischen ARTs
- Gemeinsame Inspect-&-Adapt-Zyklen für die Gesamtlösung
So hält der STE die Vielzahl an Beteiligten zusammen, ohne in ein klassisch hierarchisches Projektmanagement zu verfallen.
6.2 Solution Management
Solution Management übernimmt die Rolle der Product Manager, allerdings für die gesamte Lösung, die aus mehreren ARTs besteht.
Sie:
- definieren übergreifende Capabilities und Features
- priorisieren das Solution Backlog
- stimmen sich mit Portfolio-Ebene und Business Ownern ab
- halten die langfristige Vision der Lösung stabil, während sich Details agil entwickeln
6.3 Solution Architect
Der Solution Architect verantwortet die technische Gesamtsicht über mehrere ARTs hinweg.
Er:
- definiert Architekturprinzipien und Referenzarchitekturen
- sorgt für Konsistenz über Systemgrenzen
- arbeitet eng mit den System Architects der einzelnen ARTs zusammen
- achtet darauf, dass technische Entscheidungen zur Unternehmensstrategie passen
7. Rollen auf der Portfolio-Ebene
Auf Portfolio-Ebene geht es um Strategie, Investitionsentscheidungen und Governance.
7.1 Lean Portfolio Management (LPM)
Das Lean Portfolio Management ist ein Gremium, das Budget und Strategie mit agiler Arbeitsweise verbindet.
Es:
- definiert Strategische Themen (Strategic Themes)
- steuert Budgetzuweisungen an Wertströme und ARTs
- pflegt das Portfolio Kanban für Epics
- priorisiert Investitionen auf Basis von Wert und Risiko
Dadurch lassen sich lange Entscheidungswege verkürzen, während trotzdem eine klare strategische Steuerung erhalten bleibt.
7.2 Epic Owner
Epic Owner verantworten einzelne Business- oder Enabler-Epics auf Portfolio-Ebene.
Sie:
- formulieren Business Cases und Erfolgskriterien
- begleiten Epics durch das Portfolio Kanban
- arbeiten eng mit Product Management und LPM zusammen
- sorgen für Transparenz gegenüber Stakeholdern
Mit dieser Rolle lässt sich vermeiden, dass große Initiativen „anonym“ verlaufen, denn jede Initiative besitzt eine klar erkennbare Ansprechperson.
8. Wie die Rollen über alle Ebenen zusammenspielen
SAFe entfaltet seine Stärke, wenn Rollen und Ebenen sauber aufeinander abgestimmt agieren. Zur Veranschaulichung hilft eine typische Wertschöpfungskette:
- Strategie & Portfolio
- LPM und Business Owner definieren Strategic Themes und priorisieren Epics.
- Epic Owner treiben konkrete Initiativen voran.
- Program-/ART-Ebene
- Product Manager übersetzen Epics in Features.
- RTE und System Architect koordinieren Umsetzung und Architektur.
- Team-Ebene
- Product Owner brechen Features in User Stories herunter.
- Agile Teams liefern in Iterationen funktionierende Inkremente.
Dadurch entsteht ein roter Faden vom Unternehmensziel bis zur einzelnen User Story.
Diese Durchgängigkeit funktioniert nur, wenn Rollen aktiv miteinander kommunizieren:
- Product Manager und Product Owner stimmen regelmäßig Bedürfnisse und Prioritäten ab.
- RTE, Scrum Master und Team Coaches sorgen für Fluss und Beseitigung von Blockaden.
- System Architects und Solution Architects arbeiten eng zusammen, um technische Schulden zu begrenzen.
9. Typische Missverständnisse zu SAFe-Rollen und -Ebenen
Bei der Einführung von SAFe tauchen immer wieder ähnliche Missverständnisse auf. Ein klarer Blick auf Rollen und Ebenen hilft, diese Stolperfallen zu vermeiden.
9.1 „SAFe ist nur mehr Hierarchie“
Viele glauben, SAFe führe zusätzliche Hierarchiestufen ein. In Wirklichkeit beschreibt SAFe vor allem Verantwortungsbereiche und Kommunikationswege, nicht klassische Hierarchien.
- RTE, Product Manager oder System Architect sind keine „Chefs“, sondern Servant Leader bzw. Fachexperten.
- Entscheidungen sollen möglichst dezentral getroffen werden, aber trotzdem zur Strategie passen.
9.2 „Rollen sind nur neue Titel“
Manche Organisationen vergeben SAFe-Rollen einfach als neue Titel, ohne das dahinterliegende Mindset zu verändern.
Damit entsteht schnell Frust, weil zwar die Begriffe neu klingen, die Arbeitsweise sich jedoch kaum ändert.
Ein wirksames SAFe-Setup benötigt:
- klare Rollenbeschreibungen
- gelebte Entscheidungsrechte
- und ein gemeinsames Verständnis für Zusammenarbeit statt Silodenken
9.3 „Wir brauchen alle Ebenen sofort“
Nicht jedes Unternehmen muss sofort alle vier Ebenen einführen. Oft reicht zunächst:
- Team-Ebene + Program-Ebene (ein oder wenige ARTs)
- ein schlankes Portfolio-Board für Transparenz
Erst wenn Größe, Komplexität oder Regulierung es verlangen, lohnt sich die Large-Solution-Ebene. SAFe versteht sich bewusst als Baukasten, den du passend zu deiner Organisation zuschneidest.
10. Fazit SAFe Rollen & Ebenen einfach erklärt: SAFe-Rollen und -Ebenen als Landkarte verstehen
Wenn du SAFe zum ersten Mal siehst, wirk es manchmal überladen. Sobald du die Ebenen und Rollen jedoch als Landkarte begreifst, entsteht schnell Klarheit:
- Ebenen zeigen, auf welcher Flughöhe Entscheidungen getroffen werden.
- Rollen machen transparent, wer wofür Verantwortung übernimmt.
- Events und Artefakte verbinden diese Elemente zu einem konsistenten System.
Für die Praxis bedeutet das:
- Fokussiere dich zuerst auf Team- und Program-Ebene, damit der Agile Release Train sauber läuft.
- Kläre anschließend, welche Portfolio-Rollen du wirklich brauchst, um Strategie und Ausführung zu verknüpfen.
- Nutze Rollenbeschreibungen nicht als starre Stellenprofile, sondern als Ausgangspunkt für gelebte Zusammenarbeit.
So entsteht nach und nach ein SAFe-Setup, das agile Prinzipien skaliert, ohne sie zu verwässern, und das gleichzeitig genug Struktur für große Organisationen bietet.