GPM Regionalgruppe Chemnitz (Patrick Albert) Wegen ihres Umfangs und Komplexität sind größere SAFe-Programme bereits in Präsenz hinsichtlich ihres Managements und ihrer Steuerung anspruchsvoll. Aufgrund von COVID19 jedoch war eine Verlegung in den virtuellen Raum im beschriebenen Praxisfall unausweichlich. Das Management hatte hierbei sicherzustellen, dass die Programmziele trotz des verminderten Kontaktes allen beteiligten Teams dauerhaft klar und präsent sind und dass die in den Teams umgesetzten Funktionen außerdem den genannten Programmzielen dienen. Besonders wichtig ist dieses Alignment im Rahmen der regelmäßigen PI-Plannings, in welchen alle Teams gleichzeitig die jeweils kommenden Iterationen planen und dabei auch teamübergreifende Abhängigkeiten zuverlässig berücksichtigen müssen. Es werden Erfolgsfaktoren für den virtuellen Einsatz von SAFe herausgearbeitet und beleuchtet.

1. qaware.de
Make Agile great
PM-Erfahrungen aus einem zwei
virtuellen internationalen SAFe-Projekten
13.03.2024 | GPM Regionalgruppe Chemnitz
Patrick Albert
patrick.albert@qaware.de
linkedin.com/in/patrick-albert/

2. Patrick Albert
IT Project Manager
#mainz #qaware #agile
#cloudnative
Basics
Geboren 1983 in Mainz
Zu Hause in Rheinhessen
Frau, 2 Kinder
Ausbildung
Bis 2008: IT-Studium in Bingen
2017 - 2019: MBA IT-Management
IPMA-D
Scrum Master, Product Owner
Erfahrung
2008 - 2011: Software-Entwickler, GIP Exyr
2011 - 2021: Projektleiter, GIP Exyr
Seit 2021: IT Project Manager, QAware
Projekte bei u.a. folgenden Kunden
Deutsche Telekom Vodafone BMW diverse kleinere Firmen/Projekte
patrick-albert

3. QAware als Partner für hochwertige und ganzheitliche Software
Entwickelt als Risk Taker geschäftskritische und innovative Individualsoftware
Business Critical
Non-Essential
Commodity Competitive Advantage
Dienstleister ⇒ Partner
Standard-Software ⇒ Individualsoftware
Innovationsgrad
Geschäftskritikalität

4. SAFe in a Nutshell
Quelle : https://www.scaledagileframework.com/

5. Weitere Scaled-Agile-Frameworks
● Large-Scale Scrum (LeSS)
○ mehr Flexibilität als SAFe, da es weniger vorschreibend ist und die Anpassung an die spezifischen
Bedürfnisse des Unternehmens ermöglicht.
● Nexus
○ Konzentriert sich darauf, die Abhängigkeiten zwischen den Teams zu managen
● Scrum@Scale
○ Von Scrum-Erfinder Jeff Sutherland
○ Scrum Master-Zyklus & Product-Owner-Zyklus
○ Executive Action Team (EAT) & Scrum of Scrums (SoS)
Großer Unterschied zu SAFe:
Keine “Program Increments” (PIs)
als Zeiteinheit oberhalb der Sprints

6. Das SAFe-Projekt im Detail
Die Grundlagen
Basics
● Projektstart: 2017
● Projektende: 2023
● Planung initial mit Nexus, ab 2019 dann per SAFe
● Anfangs mit 1 Agile Release Train und ~5 Teams
(später dann mehr)
Organisation
● Sprintdauer: 2 Wochen
● Sprints im PI: 4 + IP-Sprint
● PI-Planning: jeweils 2 bzw. 3 Tage Vollzeit

7. Das SAFe-Projekt im Detail
Die Grundlagen
Staffing
● Teams mit 5-10 Mitgliedern
● Teilweise mixed zwischen Kunde und Dienstleister
● Mitarbeiter über Europa, später auch Asien verteilt
● Unser Team: Bis auf PO alle beim Dienstleister
Rollen
● 1 Product Owner & 1 Scrum Master pro Team
● 2 Release Train Engineers
● 2 Business Owner
● 1 Platform Architect

8. SAFe-Projekt in Präsenz
Es war einmal…
● Projektalltag
○ Viel Zeit in Präsenz beim Kunden vor Ort
● PI-Planning
○ ~100 Personen in Präsenz vor Ort
○ Jedes Team hat einen Tisch
(später einen eigenen kleinen Raum)
● Vorteile
○ Direkte Interaktion
○ Schnelle Entscheidungsfindung
○ Teamzusammenarbeit
○ Weniger Technologieabhängigkeit
○ Effiziente Workshops
● Nachteile
○ Reisekosten
○ Begrenzte Flexibilität
○ Physische Ressourcen
DALL-E-generiert

9. DALL-E-generiert
…und dann kam COVID19
● Wie können etablierte Prozesse “remotisiert” werden?
○ PI-Planning
○ System Demo
○ Team-interne Abläufe
● Welche Risiken bestehen?
○ Personell
○ Inhaltlich
○ Finanziell
● Welche Chancen bestehen?
○ siehe Risiken
● Welche Auswirkungen gibt es?
○ Umstrukturierung
Von nun an also Full-Remote. Alle.

10. Termine
Die vier großen SAFe-”Termine”:
■ PI-Planning
■ System-Demo
■ Retro
■ IP-Sprint

11. PI-Planning | Agenda
3 Tage planen, planen, planen
Tag 1
● Business Context & Organizational Info
● Team-interne Planungszeit
● ScrumMaster-Sync
Tag 2
● Check-In
● Team-interne Planungszeit
● ScrumMaster-Sync
● Draft Plan Review
Tag 3
● Check-In
● Draft Plan Adjustments
● Team-interne Planungszeit
● Leader-Team-Slot
● Confidence-Vote
● Final Plan

12. PI-Planning | Tooling
Übersicht per Miro

13. PI-Planning
Outcome
3 Tage Planning?
Den ganzen Tag lang?
Online?
Das muss sich ja wirklich lohnen!
Ja, tatsächlich!

14. PI-Planning | Outcome
#1: Socializing
■ Insbesondere während COVID19
■ Kontakte im eigenen Team pflegen, aber auch über Team-Grenzen hinweg
■ Gemeinsames Mittagessen und andere Pausen zwischendurch
■ Unterstützt vom Unternehmen mit Lieferando-Gutscheinen
■ Yoga-Sessions zum morgendlichen Einstieg
■ Expliziter Kommunikationsraum - im Unterschied zum “mal zwischendurch reden” im Alltag

15. PI-Planning | Outcome
#2: Team-interne Sprintplanung über 4 Sprints
■ Genutztes Tool:
“Easy Agile”-Plugin in Jira
■ Ablauf:
1. Ermittlung der verfügbaren Storypoints pro
Sprint (Urlaube, Teilzeit etc)
2. Eintragen der Storypoints in Jira
3. Zuweisen von Epics in das PI
4. Verteilen der Stories aus den Epics
in die Sprints
Quelle: EasyAgile von Atlassian

16. PI-Planning | Outcome
#3: Team-Objectives
■ Recap vom Business Context an Tag 1
– Globale Program Objectives
– Davon abgeleitete PI-Objectives
■ Aufgabe für die Teams
– Definition 4-5 Team-Objectives & Key Results für das PI
– Jeweils mit Link zu den globalen Objectives
■ Herausforderung:
Wie passen die Stories zu den Objectives?
GUT: Definition der Objectives → Finden von Stories, die darauf einzahlen.
NICHT:
Finden der Stories → Generieren von möglichst passenden Objectives
NICHT:
Definition der Objectives → Finden von Stories → Suche nach Gründen, warum sie zu den Objectives passen

17. PI-Planning | Outcome
#4: Program-Board
■ Miro-Board für den gesamten ART
– Vertikal: Sprints
– Horizontal: Teams
■ Enthält nicht zwingend alle Epics (Fokus!), aber jene…
– mit Abhängigkeiten zu anderen Teams
– mit Stakeholdern außerhalb des Teams
– relevant für globale Objectives
■ Farbkodierung für den besseren Überblick:
– Epics
• Weiß: Erledigt
• Grün: Enabler
• Blau: Feature
• Rot: Einzelne User-Story
– Pfeile
• Schwarz: Komplett abgestimmt
• Rot: Abstimmung noch notwendig
■ Diskutiert 1x pro Sprint mit allen Product Ownern & Scrum Mastern

18. PI-Planning | Risiken
● Ob remote oder live:
Bereits der rein personelle Aufwand (komplettes Projekt 3 Tage Vollzeit) führt zu hohen Kosten
● Nicht alle Anforderungen pünktlich vorhanden bzw. erst sehr kurzfristig vor dem PI-Planning
→ Hoher Planungsaufwand, und trotzdem noch offene Punkte
● Abhängigkeiten zu anderen Teams werden übersehen
→ Das fällt dann sehr kurzfristig während des PIs auf
● Aufwände werden unterschätzt

19. Regeltermine im SAFe-Projekt
System-Demo
Inhalt und Ziel der System-Demo
● Demonstration des Fortschritts über alle Teams hinweg
● Präsentation des inkrementellen Werts für Stakeholder
● Feedback-Sammlung zur Weiterentwicklung und Anpassung
Teilnehmer
● Release Train Engineer (RTE)
● Agile Teams
● Product Management
● Stakeholder (Kunden, Partner, Beta User, …)

20. Regeltermine im SAFe-Projekt
System-Demo
Vorteile
● Transparenz über den Entwicklungsfortschritt
● Frühzeitiges Erkennen von Hindernissen und Abweichungen
● Stärkung der Zusammenarbeit zwischen Teams und Stakeholdern
● Kontinuierliche Verbesserung des Produkts und des Prozesses
Remote-Setting
● Große WebEx-Session mit ~150 Teilnehmern
● Agenda wird vorher vorbereitet inkl. Zeitbedarf
● Je Beitrag 5-10 Minuten
● Konsequent moderiert durch RTE (Fragen im Chat etc)

21. Retro
Inhalt und Ziel der Retro
● Reflektieren der Zusammenarbeit
● Anbringen von neuen Ideen
Teilnehmer
● Große Runde mit allen Teams
→ “Globale” Themen besprochen
→ Beteiligung mäßig (viele Teilnehmer, aber wenig Input)
● Kleine Runde im Projekt-Team
→ Detail-Themen innerhalb des Teams
→ Idealerweise vor der großen Retro

22. Retro
Kreative Beispiele
Quelle: Miroverse.com

23. IP-Sprint
The Innovation and Planning (IP)
Iteration is a unique, dedicated
iteration that occurs every PI.
It provides an estimating buffer for
meeting PI Objectives and dedicated
time for innovation, continuing
education, PI Planning, and Inspect
and Adapt (I&A) events.
© Scaled Agile, Inc.
Include this copyright notice with the copied content.
Inhalt und Ziel des IP-Sprints
● “Feinjustierung” zur Erreichung der PI-Ziele
● Innovation (technisch, methodisch)
→ Innovation-Days
● Weiterbildung / Erfahrungsaustausch
→ KT-Sessions, Pair- / Mob-Programming
● Vorbereitung des nächsten PI-Plannings
Teilnehmer
● Projektteam

24. Separate Sync-Meetings
Projektübergreifende Sync-Meetings für separate Gruppen, jeweils 2-wöchentlich
■ SM-Sync (moderiert von RTE)
– Methodischer Austausch unter Scrum Mastern
– Steuerung Team-übergreifender Themen
■ PO-Sync (moderiert von RTE)
– Details zum großen “WAS” im Projekt
– Sind wir noch auf dem richtigen Weg?
– Passen alle aktuellen Themen in den Projekten auch wirklich auf die Gesamtziele?
■ ART-Sync (moderiert von RTE)
– Gemeinsamer Blick auf das ART-Board.
– Verschiebungen?
– Änderungen von Abhängigkeiten?
■ CoPs

25. Projekt 2
Zahlen, Daten, Fakten
Basics
● Projektstart: 2016
● Planung mit eigener Methodik
○ Kein SAFe, LeSS etc
○ Kein Agile Release Train
Organisation
● Sprintdauer: 4 Wochen
● Sprints im R-Cycle: 3
● Cycle-Planning:
○ Über mehrere Wochen verteilt
○ Gespräche Kunden-intern
○ Gespräche mit dem Kunden
○ Gespräche mit dem Team
→ Mehrstufiges Abgleichen der Themen

26. Projekt 2
Zahlen, Daten, Fakten
Staffing
● Teams mit 5-10 Mitgliedern
● Mitarbeiter über Europa verteilt
● Unser Team: Bis auf PO alle beim Dienstleister
Rollen
● 1 Scrum Master pro Team
● Mehrere (Sub-) Product Owners beim Kunden
● Cluster-Owner

27. Projekt 2
Unterschiede zu Projekt 1
Keine Standard-Methodik wie SAFe
● Kein IP-Sprint
→ “Continuous Improvement” kommt zu kurz
● Langwieriges Cycle-Planning
● Wenig Austausch wg. fehlendem ART-Sync
Fehlender Plattform-Architekt
● Stattdessen: Architektur-Board
● Entscheidungen dauern lange
● Entscheidungen nicht immer stimmig
Vielzahl von Stakeholdern
● Orthogonale Struktur der Cluster
● Diese “mischen” im Projekt mit
→ Konkurrierende Anforderungen auf Projekt-Ebene

28. Wie agile ist SAFe wirklich?
Argumente für den Einsatz von SAFe
● Strukturierte Skalierung von Agile
○ Agile Praktiken über einzelne Teams hinaus auf ganze Programme und Portfolio-Ebenen ausweiten
● Verbesserte Ausrichtung und Koordination
○ Alle Ebenen des Unternehmens auf gemeinsame Ziele ausrichten
○ bessere Koordination zwischen Teams und Abteilungen
● Erhöhte Produktivität und Qualität
○ Anwendung von Lean-Agile-Prinzipien hilft, Verschwendung zu reduzieren und Prozesse zu optimieren
○ Qualität durch technische Excellenz und gute Entwicklungspraktik sicherstellen
● Klar definierte Rollen und Verantwortlichkeiten
○ Klares Modell für Rollen und Verantwortlichkeiten in agilen Teams und auf höheren Ebenen
→ Klarheit, Transparenz und schnelle Entscheidungsfindung

29. Wie agile ist SAFe wirklich?
Argumente für den Einsatz von SAFe
● Risikominimierung
○ Regelmäßige Iterationen und Feedbackschleifen
→ frühzeitige Identifikation und Minimierung von Risiken
○ Die Flexibilität verringert das Risiko von Projektmisserfolgen
● Förderung einer Lean-Agile-Kultur
○ Förderung von kontinuierlichem Lernen, Anpassungsfähigkeit und eine proaktiver
Herangehensweise
○ Mitarbeiter in Entscheidungsprozesse einbeziehen → Motivation und Zufriedenheit
● Besseres Portfolio-Management
○ Effektive Steuerung von Investitionen in Produkte durch und Wertstrom-Management
● Beschleunigte Time-to-Market
○ Schnellere Markteinführung von Produkten und Features durch agile Praktiken

30. Wie agile ist SAFe wirklich?
Kritikpunkte
● Komplexität und Bürokratie
Ironischerweise führen die Frameworks oft zu mehr Bürokratie und Komplexität, was der agilen
Philosophie der Einfachheit und Flexibilität widerspricht.
● Einheitslösung
Sie bieten oft eine "Einheitslösung" an, die nicht auf die spezifischen Bedürfnisse oder die Kultur eines
Unternehmens zugeschnitten ist.
● Starre Planung
Themen auf langfristiger PI-Planung sind schwer agil bearbeiten.
Äußere sich ändernde Anforderungen kamen nur beschwerlich in den Team-Backlogs an
● Kosten
Die Implementierung und Aufrechterhaltung dieser Frameworks kann teuer sein, insbesondere durch
Schulungen, Zertifizierungen und Berater.

31. Wie agile ist SAFe wirklich?
Kritikpunkte
● Komplexität und Bürokratie
Ironischerweise führen die Frameworks oft zu mehr Bürokratie und Komplexität, was der agilen
Philosophie der Einfachheit und Flexibilität widerspricht.
● Einheitslösung
Sie bieten oft eine "Einheitslösung" an, die nicht auf die spezifischen Bedürfnisse oder die Kultur eines
Unternehmens zugeschnitten ist.
● Starre Planung
Themen auf langfristiger PI-Planung sind schwer agil bearbeiten.
Äußere sich ändernde Anforderungen kamen nur beschwerlich in den Team-Backlogs an
● Kosten
Die Implementierung und Aufrechterhaltung dieser Frameworks kann teuer sein, insbesondere durch
Schulungen, Zertifizierungen und Berater.
AAABER:
● Bürokratie reduzieren kann die Effektivität steigern…
…allerdings auch das Chaos
● Einheitslösungen passen zwar nicht 100% zum Unternehmen…
…sind dafür allerdings vielfach erprobt
● Starre Planung kann unagil sein…
…hilft aber auch für Roadmaps und Umsetzung von Visionen
● Framework-Einsatz kostet Geld…
…der sich in Qualität und Querschnitt rechnen kann(!)

32. Wie agile ist SAFe wirklich?
Empfehlung
● Wichtigkeit der kritischen Bewertung von Large Agile Frameworks im Kontext der eigenen
Unternehmenskultur und -ziele.
● Möglichkeit: Flexibler Ansatz, der das Beste aus Large Agile Frameworks nimmt und fokussiert an
spezifische Bedürfnisse des Unternehmens anpasst.
● Betonung auf Agilität als Mindset, nicht nur als Methode – Fokus auf kontinuierliche Verbesserung,
Anpassungsfähigkeit und Kundenwert.
● Ermutigung zur Innovation innerhalb der Teams, um Prozesse zu entwickeln, die wirklich agil und effektiv
für ihre spezifische Situation sind.

33. Lass es
gut
werden!
Pixabay

34. Lass es
gut
werden!
P
r
o
j
e
k
t
-
I
d
e
n
t
i
t
ä
t
Team
gedanke Gem
einsam
es
Toolset
Passendes
Setup
K
o
m
m
u
n
i
k
a
t
i
o
n
s
-
R
e
g
e
l
n
Passendes Setup
■ Welche Rolle auf welcher Seite?
■ Sinnvoll für beide Seiten
■ Klare Zuständigkeiten und Mandate
Kommunikationsregeln
■ Wer mit wem?
■ Zu welchem Thema?
■ Wann und wie?
Gemeinsames Toolset
■ Messaging
■ Collaboration
■ Development
■ Management
Teamgedanke
■ Vertrauen aufbauen
■ Für Transparenz sorgen
■ Regelmäßige Retrospektiven
Projektidentität
■ Kultur
■ Logo

35. Vielen Dank!
Habt Ihr Fragen?