SAFe® 6 für Teams: Agile Zusammenarbeit im Agile Release Train

Seminarziel

 Jede teilnehmende Person verlässt das Seminar mit einem Verständnis ihrer Rolle im ART (Team-Topologie, Zusammenarbeit, Rollen), der Erfahrung eines simulierten PI Planning (Objectives, Abhängigkeiten, Confidence Vote), einem Team Canvas und Definition of Done , Kenntnis der SAFe-6.0-Praktiken (Built-in Quality, Flow-Metriken, Continuous Delivery Pipeline, KI-Unterstützung) und der Vorbereitung auf die SP-Zertifizierungsprüfung .

Inhalt

Tag 1: SAFe verstehen, im Team agil arbeiten
1. SAFe® 6 im Überblick: Warum skalierte Agilität?

• Das Skalierungsproblem:   Ein Scrum-Team funktioniert. Aber was passiert, wenn 5, 10 oder 50  Teams an einem Produkt arbeiten? Abhängigkeiten, unterschiedliche  Prioritäten, Integrationsprobleme, lange Lieferzyklen. SAFe organisiert  die Zusammenarbeit dieser Teams.
• SAFe 6.0 - die 7 Kernkompetenzen:   Team and Technical Agility, Agile Product Delivery, Enterprise Solution Delivery, Lean Portfolio Management, Organizational Agility, Continuous Learning Culture, Lean-Agile Leadership. Wo steht das Team in diesem Bild?
• Der Agile Release Train (ART):   50-125 Personen, 5-12 Teams, ein gemeinsames Mission und Vision,  synchronisiert durch PI Planning. Der ART ist das Herzstück von SAFe -  und das Team ist seine Grundeinheit.
• Rollen im ART:   Release Train Engineer (RTE - koordiniert den ART), Product Management  (Programm-Backlog), System Architect (technische Richtung), Scrum  Master/Team Coach (Team-Ebene), Product Owner (Team-Backlog),  Teammitglieder (Entwicklung, Test, Analyse). Wo passe ich rein?
• SAFe-Werte: Alignment, Built-in Quality, Transparency, Program Execution. Was jeder Wert für die tägliche Arbeit bedeutet.
• SAFe und KI (neu in 6.0):   AI-assisted Practices - KI-gestützte Backlog-Priorisierung,  automatisierte Testgenerierung, KI-basierte Flow-Analyse. Was ändert  sich für Teams?

2. Agile Teams in SAFe: Aufbau und Zusammenarbeit

• Cross-funktionale Teams:   Jedes Team hat alle Kompetenzen, um Features end-to-end zu liefern -  Entwicklung, Test, UX, Business-Analyse. Keine Übergaben zwischen  Abteilungen, sondern Zusammenarbeit innerhalb des Teams.
• Team-Topologien in SAFe:   Stream-aligned Teams (liefern Kundenwert), Enabling Teams (helfen  anderen Teams bei neuen Technologien), Platform Teams (stellen  Infrastruktur bereit), Complicated-Subsystem Teams (spezialisierte  Technologie). Welcher Typ ist mein Team?
• Team of Agile Teams:   Wie Teams innerhalb des ART zusammenarbeiten - ART Sync (alle 2  Wochen), System Demo (integriertes Ergebnis aller Teams), Scrum of  Scrums (Impediment-Klärung), Communities of Practice (Wissensaustausch  über Teams hinweg).
• Built-in Quality:   Qualität ist keine Phase, sondern ein Prinzip. Pair Programming,  Test-Driven Development, Continuous Integration, Code Reviews,  Collective Ownership. SAFe 6.0 definiert Built-in Quality als nicht  verhandelbar - ohne Qualität kein nachhaltiges Tempo.
• Praxis-Übung:   Team Canvas ausfüllen - Mission des Teams, Stakeholder, Kompetenzen,  Arbeitsvereinbarungen, Definition of Done. In Kleingruppen: ein fiktives ART-Team aufsetzen.

3. Iteration Planning und Execution: Die Teamebene im Detail

• Iteration Planning:   Kapazität bestimmen (verfügbare Tage × Fokus-Faktor), Stories aus dem  Team-Backlog auswählen, Tasks identifizieren, Iteration Goals  formulieren. Unterschied zu klassischem Sprint Planning: Stories kommen  aus den PI-Objectives, nicht nur aus dem Backlog.
• User Stories schreiben und schätzen:   Story-Format (Als... möchte ich... damit...), Akzeptanzkriterien  (Given-When-Then), Story-Splitting (vertikaler Schnitt,  INVEST-Kriterien). Relative Schätzung mit Story Points (Fibonacci).  Brücke zum GFU-Seminar „RE für Product Owner" (NEU, 2T).
• Features in Stories aufschlüsseln:   Ein Feature (Programm-Ebene) wird in 3-8 Stories (Team-Ebene) zerlegt.  Der PO zerlegt, das Team schätzt und validiert. Acceptance Criteria des Features bestimmen die Stories.
• Team-Kanban:   Visualisierung des Arbeitsflusses - To Do -> In Progress -> Review ->  Done. WIP-Limits pro Spalte. Blocker sichtbar machen. Cumulative Flow  Diagram für Flow-Analyse.
• Daily Stand-up im SAFe-Kontext:   15 Minuten, am Board. Nicht „Was habe ich getan?" sondern „Wie fließt  die Arbeit? Wo steckt etwas fest? Brauche ich Hilfe?" Fokus auf Flow,  nicht auf Personen.
• Iteration Review und Retrospektive:   Review: funktionsfähiges Inkrement dem PO und Stakeholdern zeigen.  Retrospektive: Was verbessern wir in der nächsten Iteration? Ein  konkretes Improvement-Item ins Backlog aufnehmen.
• Praxis-Übung:   Iteration Planning simulieren - aus einem vorgegebenen Feature 5  Stories ableiten, schätzen (Planning Poker), Tasks identifizieren,  Iteration Goal formulieren. Kanban-Board aufsetzen.

Tag 2: PI Planning, ART-Zusammenarbeit und kontinuierliche Verbesserung
4. PI Planning: Das zentrale SAFe-Event

• Was ist PI Planning?   Das wichtigste Event in SAFe - alle Teams des ART kommen für 2 Tage  zusammen und planen die nächsten 8-12 Wochen (ein Program Increment =  4-6 Iterationen). Alignment, Commitment, Transparenz.
• PI Planning Vorbereitung (Team-Perspektive):   Backlog Refinement vor dem PI Planning - Features verstehen, Fragen  klären, erste Story-Ideen sammeln. Kapazität für das PI berechnen.  Abhängigkeiten zu anderen Teams vorab identifizieren.
• PI Planning Ablauf:   Tag 1: Business Context (Product Management), Architektur-Vision  (System Architect), Team Breakouts (Features -> Stories -> Schätzung -> PI  Objectives), Management Review. Tag 2: Adjustments, Risiken  identifizieren (ROAM: Resolved, Owned, Accepted, Mitigated), Confidence  Vote, Plan-Finalisierung.
• PI Objectives formulieren:   Jedes Team formuliert 5-10 PI Objectives - was liefern wir in diesem  PI? Committed Objectives (verlässlich lieferbar) vs. Uncommitted  Objectives (angestrebt, aber unsicher). Business Value pro Objective  (vom Product Management bewertet).
• Abhängigkeiten managen:   Programm-Board - rote Fäden zwischen Teams sichtbar machen. „Wir  brauchen die API von Team A in Iteration 2, damit wir in Iteration 3 das Frontend bauen können." Abhängigkeiten sind kein Problem - unsichtbare Abhängigkeiten sind das Problem.
• Confidence Vote:   Am Ende des PI Planning stimmt jedes Teammitglied ab: „Wie  zuversichtlich bin ich, dass wir unsere PI Objectives erreichen?" (1-5  Finger). Unter 3 -> Diskussion und Anpassung. Der Confidence Vote ist  kein Ritual, sondern ein Frühwarnsystem.
• Praxis-Übung:   PI Planning Simulation - in Kleingruppen (je ein „Team") ein PI planen: 3 Features aufschlüsseln, PI Objectives formulieren, Abhängigkeiten auf dem Programm-Board markieren, Confidence Vote durchführen.

5. PI Execution: Wert liefern über mehrere Iterationen

• Iteration Execution im PI-Kontext:   Jede Iteration arbeitet auf die PI Objectives hin. Der PO priorisiert  Stories so, dass die Committed Objectives zuerst bedient werden.  Veränderungen innerhalb des PI sind erlaubt, aber die PI Objectives  bleiben stabil.
• System Demo:   Alle 2 Wochen zeigen alle Teams des ART gemeinsam das integrierte  Ergebnis - nicht einzelne Team-Inkremente, sondern das Zusammenspiel.  Funktioniert die Integration? Gibt es Konflikte? Ist der  Gesamtfortschritt auf Kurs?
• ART Sync und Scrum of Scrums:   Wöchentliche Synchronisation der Scrum Master/Team Coaches -  Impediments, Abhängigkeiten, Risiken. Nicht jeder redet über alles,  sondern: Was blockiert uns? Was brauchen wir von anderen Teams?
• Innovation and Planning (IP) Iteration:   Die letzte Iteration im PI ist reserviert für: Hackathons, technische  Schulden abbauen, Weiterbildung, Vorbereitung des nächsten PI Planning,  Inspect & Adapt. Keine Feature-Arbeit - bewusster Freiraum für  Innovation und Verbesserung.
• Metriken auf Team-Ebene:   Velocity (Story Points pro Iteration), Flow-Metriken (Cycle Time,  Throughput, WIP), Predictability Measure (geplant vs. geliefert pro PI). SAFe 6.0 betont Flow-Metriken stärker als Velocity.
• Praxis-Übung:   Iteration Execution durchspielen - 2 „Iterationen" im Zeitraffer (je 15 Min), dabei Kanban-Board aktualisieren, Blocker identifizieren, System Demo vorbereiten.

6. Continuous Delivery Pipeline und DevOps in SAFe

• Continuous Exploration:   Was sollen wir bauen? Design Thinking, Customer Centricity, Lean  Startup. Features werden nicht einfach bestellt, sondern durch  Hypothesen und Validierung entwickelt.
• Continuous Integration:   Teams integrieren ihren Code mehrfach täglich - automatisierte Builds,  automatisierte Tests, Feature Toggles. „If it hurts, do it more often."
• Continuous Deployment:   Vom Code-Commit bis zur Produktion - automatisierte Pipelines,  Staging-Umgebungen, Blue-Green Deployments, Canary Releases. Der ART  liefert nicht am PI-Ende, sondern kontinuierlich.
• Release on Demand:   Die Entscheidung „Wann releasen?" ist eine Business-Entscheidung, keine technische. Features können jederzeit released werden, wenn sie fertig und validiert sind - unabhängig vom PI-Rhythmus.
• DevOps im SAFe-Kontext:   Collaboration and Culture, Automation, Lean Flow, Measurement, Recovery (CALMR). Brücke zum GFU-Seminar „SAFe® DevOps Practitioner" (geplant) und zum DevOps-Portfolio (K8s, CI/CD, Terraform).

7. Inspect & Adapt: Kontinuierliche Verbesserung auf ART-Ebene

• Inspect & Adapt Event:   Am Ende jedes PI - drei Teile: PI System Demo (Gesamtergebnis des PI an Stakeholder), Quantitative Measurement (PI Objectives erreicht?  Predictability?), Problem-Solving Workshop (größtes Impediment  identifizieren und Gegenmaßnahme planen).
• Problem-Solving Workshop:   Strukturiert nach dem „Fishbone Diagram" oder „5 Whys" - nicht Symptome behandeln, sondern Ursachen finden. Ergebnis: Improvement Stories, die im nächsten PI eingeplant werden.
• Relentless Improvement:   SAFe-Prinzip - jedes PI ein bisschen besser. Nicht revolutionäre  Veränderung, sondern inkrementelle Verbesserung in jedem Zyklus. Teams,  ARTs und Portfolio verbessern sich parallel.
• Praxis-Übung:   Mini-Inspect & Adapt - das PI Planning aus Topic 4 auswerten:  Wurden die Objectives erreicht? Was war das größte Impediment? Eine  Improvement Story formulieren.

8. Praxis-Workshop: „Unser erstes PI"
Phase 1 - Team-Setup und Backlog (15 Min):

• Team Canvas erstellen (Mission, Rollen, Arbeitsvereinbarungen).
• 3 Features aus einem Programm-Backlog übernehmen und in Stories zerlegen.

Phase 2 - PI Planning Simulation (30 Min):

• PI Objectives formulieren (Committed + Uncommitted).
• Abhängigkeiten zu anderen Teams auf dem Programm-Board markieren.
• Risiken identifizieren (ROAM).
• Confidence Vote durchführen.

Phase 3 - Iteration und System Demo (15 Min):

• Eine Iteration planen (Stories auswählen, Tasks identifizieren).
• System Demo vorbereiten (was zeigen wir?).

Phase 4 - Prüfungsvorbereitung (30 Min):

• Überblick über die SAFe® 6 Practitioner (SP)-Prüfung: 45 Fragen, 90 Minuten, 77 % Passing Score.
• 15 Beispielfragen gemeinsam durchgehen - typische Fallstricke besprechen.
• Trailhead-äquivalente  Lernressourcen und Prüfungsanmeldung (Prüfung innerhalb von 30 Tagen  nach dem Seminar, erster Versuch im Seminarpreis enthalten).