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.
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Projekten
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.
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
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.