SlideShare ist ein Scribd-Unternehmen logo
1 von 36
Downloaden Sie, um offline zu lesen
Backlog Refinement Flow @ Scale
&
@ Large Scale
9. November 2020
Rick.Janda@kegon.ch Marco.Wyttenbach@swisscom.ch
Large Solution «Omni Channel Experience (OCE)»
▪ 2 Solution Manager
▪ 5 Trains
▪ 14 Product Manager
▪ 40 Teams
▪ 40 Product Owner
▪ 350 Mitarbeiter
PMs
POs
PI-Planning
100%
PM/PO-Load
PI-Planning
Grundlegende Transparenz – Upstream Kanban
Funnel PM im Lead PO im Lead Ready 4
PI-Planning
Quantifizieren – Vision – Hindernisse - Massnahmen
PM-Sicht
Aufwand pro Feature:
2.5 Tage
Flow-Effizienz: 6%
Einladungsflut
Umstellen auf Pull - am Eingang!
Das!Nutzen?
Finde einen gemeinsamen Termin…
Feature-Flightcrew und Train-Friends
Nächster Halt:
Nächste Kanban-Spalte Auch ein Train braucht Freunde
Feature-Refinement-Blocker und Flightcrew-Planung
Jeden Donnerstag: Jeden Dienstag:
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.
Wöchentliches “Walk the Kanban”
Was und vor allem Wen braucht es alles,
damit das Feature eine Spalte weiter kommt?
Krümel-Feature rauben viel Zeit
20%
80%Feature Breakdown
PO-Hoheit
Team Backlog Capacity Allocation
Shu-Level-Unterstützung: Feature Templates passend
zum Kanban
Von Perfektionismus zu gut genug für jetzt
Team Load Forecast
→Stakeholder-Management
→Teamwechsel vermeiden
Was haben wir erreicht?
50d 46d
32d
Phase Out
ART S2A
Was haben wir erreicht? - Durchlaufzeiten
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
Aufgetretene Probleme
▪ Engpässe wurden sichtbar
▪ Train-übergreifende Zusammenarbeit problematisch
Dank Struktur zu Flow
Teil 2 – Flow über mehrere ARTs erreichen
Ziel: Flow
Liegezeit minimieren, Richtungswechsel vermeiden, vorwärts zum gemeinsamen Ziel
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.
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
PFSync
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
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
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"
Zwischenergebnis: gemeinsam starten hilft
Die Orientierung und das gemeinsame Ziel fehlen irgendwie trotzdem…
CapabilityPortfolioEpicFeatureStorie
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.
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.
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.
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
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
Update - Ergebnis
Reduktion der PI Preparation Zeit auch auf Ebene Large Solution
63d
42d
55d 29d
https://www.kegon.ch
Rick.Janda@kegon.ch
https://www.wyttenbach4flow.com
Marco.Wyttenbach@swisscom.ch

Weitere ähnliche Inhalte

Ähnlich wie Backlog Refinement Flow @ Large Scale (9. Nov. 2020)

oVirt 3.5 - Einführung und Evaluierungsergebnisse
oVirt 3.5 - Einführung und EvaluierungsergebnisseoVirt 3.5 - Einführung und Evaluierungsergebnisse
oVirt 3.5 - Einführung und Evaluierungsergebnisseinovex GmbH
 
LKCE 17 Vortrag: Kanban in SAFe Waters
LKCE 17 Vortrag: Kanban in SAFe WatersLKCE 17 Vortrag: Kanban in SAFe Waters
LKCE 17 Vortrag: Kanban in SAFe WatersSusanne Bartel
 
Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)
Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)
Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)Stefan ROOCK
 
Logistikprozesse im laufenden Betrieb optimieren
Logistikprozesse im laufenden Betrieb optimierenLogistikprozesse im laufenden Betrieb optimieren
Logistikprozesse im laufenden Betrieb optimierenLean Knowledge Base UG
 
Agiles Projekt-Controlling
Agiles Projekt-ControllingAgiles Projekt-Controlling
Agiles Projekt-ControllingAndreas Czakaj
 
MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)Ulf Mewe
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererTobias Schlüter
 
Scrum days 2016_scrum_bei_festo_frank-m.hoyer_nadine.kärcher
Scrum days 2016_scrum_bei_festo_frank-m.hoyer_nadine.kärcherScrum days 2016_scrum_bei_festo_frank-m.hoyer_nadine.kärcher
Scrum days 2016_scrum_bei_festo_frank-m.hoyer_nadine.kärcherJuergen Hohnhold
 
Configuration Management (Fokus: Version-Controlling) – Best Pracitces
Configuration Management (Fokus: Version-Controlling) – Best PracitcesConfiguration Management (Fokus: Version-Controlling) – Best Pracitces
Configuration Management (Fokus: Version-Controlling) – Best Pracitceskaftanenko
 
Surf 'n' Turf - Scrum und ECSS-E-ST-40C
Surf 'n' Turf - Scrum und ECSS-E-ST-40CSurf 'n' Turf - Scrum und ECSS-E-ST-40C
Surf 'n' Turf - Scrum und ECSS-E-ST-40CStefan Wertheimer
 
OOP 2012 - Udo Pracht - DevOps Einführung und Überblick
OOP 2012 - Udo Pracht - DevOps Einführung und ÜberblickOOP 2012 - Udo Pracht - DevOps Einführung und Überblick
OOP 2012 - Udo Pracht - DevOps Einführung und ÜberblickUdo Pracht
 
1. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.20231. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.2023Johannes Kleinlercher
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernSascha Böhr
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightChristinaLerch1
 
edutrainment Webtalk Agiles Arbeiten
edutrainment Webtalk Agiles Arbeitenedutrainment Webtalk Agiles Arbeiten
edutrainment Webtalk Agiles Arbeitenedutrainment company
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudAarno Aukia
 
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Virtual Forge
 

Ähnlich wie Backlog Refinement Flow @ Large Scale (9. Nov. 2020) (20)

oVirt 3.5 - Einführung und Evaluierungsergebnisse
oVirt 3.5 - Einführung und EvaluierungsergebnisseoVirt 3.5 - Einführung und Evaluierungsergebnisse
oVirt 3.5 - Einführung und Evaluierungsergebnisse
 
LKCE 17 Vortrag: Kanban in SAFe Waters
LKCE 17 Vortrag: Kanban in SAFe WatersLKCE 17 Vortrag: Kanban in SAFe Waters
LKCE 17 Vortrag: Kanban in SAFe Waters
 
Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)
Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)
Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)
 
Murcs
MurcsMurcs
Murcs
 
Logistikprozesse im laufenden Betrieb optimieren
Logistikprozesse im laufenden Betrieb optimierenLogistikprozesse im laufenden Betrieb optimieren
Logistikprozesse im laufenden Betrieb optimieren
 
Agiles Projekt-Controlling
Agiles Projekt-ControllingAgiles Projekt-Controlling
Agiles Projekt-Controlling
 
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-EntwicklungOOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
 
MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
Scrum days 2016_scrum_bei_festo_frank-m.hoyer_nadine.kärcher
Scrum days 2016_scrum_bei_festo_frank-m.hoyer_nadine.kärcherScrum days 2016_scrum_bei_festo_frank-m.hoyer_nadine.kärcher
Scrum days 2016_scrum_bei_festo_frank-m.hoyer_nadine.kärcher
 
Configuration Management (Fokus: Version-Controlling) – Best Pracitces
Configuration Management (Fokus: Version-Controlling) – Best PracitcesConfiguration Management (Fokus: Version-Controlling) – Best Pracitces
Configuration Management (Fokus: Version-Controlling) – Best Pracitces
 
Surf 'n' Turf - Scrum und ECSS-E-ST-40C
Surf 'n' Turf - Scrum und ECSS-E-ST-40CSurf 'n' Turf - Scrum und ECSS-E-ST-40C
Surf 'n' Turf - Scrum und ECSS-E-ST-40C
 
OOP 2012 - Udo Pracht - DevOps Einführung und Überblick
OOP 2012 - Udo Pracht - DevOps Einführung und ÜberblickOOP 2012 - Udo Pracht - DevOps Einführung und Überblick
OOP 2012 - Udo Pracht - DevOps Einführung und Überblick
 
1. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.20231. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.2023
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
 
Agile Methoden in Projekten
Agile Methoden in ProjektenAgile Methoden in Projekten
Agile Methoden in Projekten
 
edutrainment Webtalk Agiles Arbeiten
edutrainment Webtalk Agiles Arbeitenedutrainment Webtalk Agiles Arbeiten
edutrainment Webtalk Agiles Arbeiten
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
 
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
 

Backlog Refinement Flow @ Large Scale (9. Nov. 2020)

  • 1. Backlog Refinement Flow @ Scale & @ Large Scale 9. November 2020 Rick.Janda@kegon.ch Marco.Wyttenbach@swisscom.ch
  • 2. Large Solution «Omni Channel Experience (OCE)» ▪ 2 Solution Manager ▪ 5 Trains ▪ 14 Product Manager ▪ 40 Teams ▪ 40 Product Owner ▪ 350 Mitarbeiter
  • 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%
  • 7. Umstellen auf Pull - am Eingang! Das!Nutzen?
  • 9. Feature-Flightcrew und Train-Friends Nächster Halt: Nächste Kanban-Spalte Auch ein Train braucht Freunde
  • 11.
  • 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?
  • 17. Von Perfektionismus zu gut genug für jetzt
  • 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 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 PFSync 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. CapabilityPortfolioEpicFeatureStorie 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 63d 42d 55d 29d