Ca. 350 Mitarbeitende entwickeln und betreiben bei der Swisscom die Applikationen zur Unterstützung der verschiedenen Verkaufs- und Support-Kanäle. Die über 30 Teams werden über zwei Skalierungsstufen in einer SAFe Large Solution koordiniert. Auf unterster Ebene verantwortet der Product Owner jedes Teams den Backlog des Teams. Die Teams sind in fünf Agile Release Trains (ARTs) zusammengefasst. Der Backlog jedes ARTs wird von jeweils einem Product-Management-Team verantwortet. Zwei Solution-Manager verantworten den übergreifenden Backlog über die fünf ARTs. Alle zehn Wochen kommen die fünf ARTs in parallel stattfindenden PI-Plannings zusammen, definieren ihren Fokus für die nächsten zehn Wochen und identifizieren Abhängigkeiten zwischen den Teams und ARTs. Vorbereitet werden die Inhalte für diese PI-Plannings in Zusammenarbeit von Solution-Managern, Product-Managern, Product-Ownern und weiteren Personen wie Architekten und UX-Leads. Dabei wurden wir mit diesen Problemen konfrontiert: - Keine Fokussierung: Permanent überlastete Product- und Solution-Manager wegen paralleler Themenbearbeitung. - Kein Continuous Refinement: Product Owner werden kurz vor den PI-Plannings mit Themen überrollt. - Hang zu Pixelperfect vor PI Planning: Einfache Vorhaben verbringen zu viel Zeit in der Vorbereitung. Marco und Rick zeigen Lösungen die sie gemeinsam in 1 ½ Jahren mit Erfolg implementiert haben. Marco Wyttenbach ist einer der zwei Solution Manager dieser Large Solution. Rick Janda ist Enterprise Agile Coach der KEGON Schweiz.

1. Backlog Refinement Flow @ Scale
&
@ Large Scale
3. März 2021 – Agile Breakfast Zürich
Rick.Janda@kegon.ch Marco.Wyttenbach@swisscom.ch

2. Large Solution «Omni Channel Experience (OCE)»
40 Teams
5 Trains
Solution Manager STE

3. PMs
POs
PI-Planning
100%
PM/PO-Load
PI-Planning

4. Grundlegende Transparenz – Upstream Kanban
Funnel PM im Lead PO im Lead Ready 4
PI-Planning

5. Quantifizieren – Vision – Hindernisse - Massnahmen
PM-Sicht
Aufwand pro Feature:
2.5 Tage
Flow-Effizienz: 6%

6. Einladungsflut

7. Umstellen auf Pull - am Eingang!
Das!
Nutzen?

8. Finde einen gemeinsamen Termin…

9. Feature-Flightcrew und Train-Friends
Nächster Halt:
Nächste Kanban-Spalte Auch ein Train braucht Freunde

10. Feature-Refinement-Blocker und Flightcrew-Planung
Jeden Donnerstag: Jeden Dienstag:

12. Zu welchem PO?
• Akzeptanz-Kriterien?
• Betroffene Systeme?
• Am stärksten betroffenes System?
• Verantwortliches Team?
• Ihr PO übernimmt den Lead.
Jeweils nur soviel, um die nächste Frage zu
beantworten.

13. Wöchentliches “Walk the Kanban”
Was und vor allem Wen braucht es alles,
damit das Feature eine Spalte weiter kommt?

14. Krümel-Feature rauben viel Zeit

15. 20%
80%
Feature Breakdown
PO-Hoheit
Team Backlog Capacity Allocation

16. Shu-Level-Unterstützung: Feature Templates passend
zum Kanban

17. Von Perfektionismus zu gut genug für jetzt

18. Team Load Forecast
→Stakeholder-Management
→Teamwechsel vermeiden

19. Was haben wir erreicht?

20. 50d 46d
32d
Phase Out
ART S2A
Was haben wir erreicht? - Durchlaufzeiten

21. Erfolgsfaktoren
▪ Starker Lead-PM
▪ Überlast der PMs/POs als
Treiber für Veränderung
▪ Wöchentlicher Rhythmus
▪ Kochrezepte
Massnahmen
▪ 30 Minuten Kaffee
▪ Feature-Flightcrew
▪ Blocker für Train-Friends
▪ Frühe PO-Übergabe
▪ Kekskrümeln dezentralisieren
▪ Team-Load-Forecast
▪ JIRA-Templates and DoR

22. Aufgetretene Probleme
▪ Engpässe und Kompetenz-Lücken wurden sichtbar
▪ Train-übergreifende Zusammenarbeit problematisch

23. Dank Struktur zu Flow
Teil 2 – Flow über mehrere ARTs erreichen

24. Ziel: Flow
Liegezeit minimieren, Richtungswechsel vermeiden, vorwärts zum gemeinsamen Ziel

25. Die Outlook Kalender von vier PMs beim Versuch einen notwendigen
gemeinsamen, einstündigen Termin innerhalb einer Woche zu finden.
Ausgangslage
Wenig Zeit für Alignment, keine gemeinsamen Prioritäten, viele gegenseitige Erwartungen
Die PMs haben die Themen verfolgt, die für ihre ARTs relevant waren -
eine gemeinsame Priorisierung gab es nicht.
Abhängigkeiten wurden "on the fly" erkannt, die Flexibilität der anderen für
die Bearbeitung einfach vorausgesetzt aber nicht gemanagt.

26. Massnahme: Prioritäten gemeinsam setzen
Auch gemeinsam Prioritäten festlegen ist eine Transformation
v0.1 – Top5 je ART v0.5 – übergreifende Top5 + ART Top5 v1.0 – übergreifend overall + Freiheit für ARTs
Rank
PF
Sync
BRR
WSJF
ID
0 0 n.a. 21 n.a.
1 1 23 1.60 OCECAP-546
2 2 23 1.63 OCECAP-539
3 3 21 1.00 OCECAP-550
4 5 35 0.62 OCECAP-551
5 10 11 1.00 OCECAP-549
6 13 14 0.62 OCECAP-552
7 11 14 1.00 OCECAP-525
8 8 29 1.13 OCECAP-412
9 9 n.a. 0.80 OCECAP-203
10 15 n.a. 1.00 OCECAP-329
11 4 21 1.00 OCECAP-534
12 20 29 1.00 OCECAP-515
13 6 35 0.62 OCECAP-527

27. Massnahme: Checks and Balances
Der limitierende Faktor muss die "Pull"-Entscheide fällen können um WIP zu limitieren
Jeder Status "gehört" einer Rolle
BO = Business Owner
Rolle, die das Business Zielbild verantwortet
und die Vorhaben zum Erreichen des
Zielbildes priorisiert, auf einer (Wunsch-
)Roadmap abbildet und auf Seiten OVS
priorisiert. Ein BO verantwortet zudem den
Business Case der Vorhaben sowie dessen
Validierung und die Operationalisierung. Der
BO begleitet den laufenden Betrieb
hinsichtlich Effizienzoptimierung und
monitort KPI/OKR.
SolM = Solution Manager
Product Owner für ARTübergreifende Themen
(Capabilities/Solution Epic)
PM = Product Manager
Product Owner für teamübergreifende
Themen (Feature/Program Epic)
PO = Product Owner auf Teamebene

28. Massnahme: Sprintstruktur für PI Preparation
Termine für die ganze Large Solution in eine Sequenz bringen – Fokus "gemeinsam starten"
Solution Train Sync
"walk the Kanban"
Cap Refinement
Readiness Capability für
Status "Analysis"
ART Backlog Mgmt
"walk the Kanban"
Feature Refinement
Readiness Feature für Status
"Analysis"

29. Zwischenergebnis: gemeinsam starten hilft
Die Orientierung und das gemeinsame Ziel fehlen irgendwie trotzdem…

30. Capability
Portfolio
Epic
Feature
Storie
Open/Ack Analysis Backlog …
Funnel
According to DoR
Massnahme: Ablauf anhand von Regeln abbilden
Zusammenhang zwischen über- und untergeordnetem Element im Ablauf herstellen
Regel von "Funnel" nach "Analysis"
Erst wenn ein übergeordnetes Element den
Status "Analysis" erreicht, dürfen die
darunterliegenden Elemente den Status
"Funnel" verlassen.
Regel von "Analysis" nach "Backlog"
Erst wenn alle untergeordneten Elemente den
Status "Backlog" erreichen, darf das
darüberliegende Element in den Status
"Backlog" gezogen werden.

31. Massnahme: "Flight Crew"-Ansatz auf Ebene Large Solution
Standardtermine an potentiell Betroffene senden und rechtzeitig mit Agenda aktualisieren
Prinzip
Regelmässig von Capabilities betroffene agile Teams ausserhalb der Large Solution und alle ART-Vertreter innerhalb der Large Solution haben einen
wöchentlichen Standardtermin. Die Agenda des Termins wird spätestens einen Tag, fröhestens eine Woche vor Capability Refinement kommuniziert. Die
Pflichtteilnehmer sind definiert – alle anderen können dennoch entscheiden, ob es sie für das Refinement braucht. Je Thema steht rund eine Stunde Zeit
zur Verfügung.

32. Massnahme: Templates
Jira-Items bzgl. Output verstehen und in Templates Inhalte für "ready to be pulled" vorgeben
Prinzip
Die Templates erlauben einen Fokus je "Flughöhe" auf die zu liefernden Inhalte und bieten ausreichend Informationstiefe in übergeordneten Elementen für
Hintergrundinformationen.

33. Massnahme: Ablauf der Regeln in Meetings abbilden
Als Shu-Massnahme darf der Status im Kanban nur in bestimmten Meetings wechseln
Solution Train Sync
"walk the Kanban"
Pull to "open/ack"
Flight Crew Cap Refinement
Cap Refinement
Readiness Capability für "Analysis"
i) Beitrag je ART
ii) Acceptance Criteria
iii) Relevante Personen + Lead
ART Backlog Mgmt
"walk the Kanban"
Pull to "open/ack"
Flight Crew Feat Refinement
Feature Refinement
Readiness Feature für "Analysis"
i) Beitrag je Team
ii) Acceptance Criteria
iii) Relevante Personen + Lead

34. In a nutshell
Was haben wir bis heute alles eingeführt, was haben wir erreicht
Was haben wir eingeführt
• Gemeinsam Prioritäten festlegen
• Sprintstruktur für PI Preparation – gemeinsam starten, gleichzeitig
Verständnis schaffen, gemeinsam Ziel definieren
• Checks and Balances – "pull" gesteuert durch
den limitierenden Faktor
• Ablauf anhand von Regeln –
Zusammenhang von Elementen herstellen
• "Flight Crew" – Alignment über
die Large Solution Disziplinen hinaus
• Jira Templates – Efforts abbilden, Output je Jira Item definieren,
"Waste" reduzieren
• Abbilden der Regeln in Meetings
Shu-Massnahme für forciertes Alignment
Smart Simplicity (2014, Yves Morieux):
"Desired behaviours spontaneously emerge when you adequately change the context; feelings and values will follow"
Change Management (1983, John Shook):
"It’s easier to act your way to a new way of thinking than to think your way to a new way of acting."
Was haben wir damit erreicht
• Weniger Diskussionen am PI Planning
• Deutlich besseres Alignment je erarbeitetem Thema
• Weniger Vorlaufzeit notwendig um transversale Themen zu
erarbeiten
• Klarere Kommunikation und besseres Erwartungsmanagement
gegenüber dem Business Owner und/oder Mgmt
• "Flow v0.8" – deutlich verbessert, wenn auch noch nicht im
Zielzustand
• Doing Agile

35. Update - Ergebnis
Reduktion der PI Preparation Zeit auch auf Ebene Large Solution
65d
40d
59d
45d

36. https://www.kegon.ch
Rick.Janda@kegon.ch
https://www.wyttenbach4flow.com
Marco.Wyttenbach@swisscom.ch

37. Return on Time Invest