Slides from my Lean and Agile Coffee presentation in Vienna

1. Lean & Agile Coffee Vienna
Anwenderbeispiel Kanban Flight Levels
Michael Rumpler
Leiter Entwicklung
PKE Electronics AG

2. Kanban Flight Levels
2

3. KABA MIC AWM
Rümlang, Wetzikon (CH)
Leonberg, Villingen-Schwenningen (DE)
Entwicklung (HW, SW, Produktion)
Produktion (Mechanik, Mechatronik, Elektronik)
Beispiel 1

5. Beispiel Kaba MIC AWM
5
Produktmanagement Produktmanagement Produktmanagement
Quality Assurance
Project Management / Requirements Eng.
Die Entwicklungsorganisation (vereinfacht)

6. Ausgangslage
6
• 2 Scrum Teams für das größte Produkt
• Scrum (but) Prozess
• Viele Abhängigkeiten (die zu Waste führten)
• Ineffiziente Resourcennutzung
• Nicht auf Optimierung des Flow ausgerichtet

7. Schritt 1: Team-Zusammenlegung
7
12 Entwickler
4 Tester
2 Techn. Redakteure
3 POs
3 PMs

8. Team Level
8

9. Prozessdetails Team Level
9
• 4 unabhängige «Feature Trains»
• Das Team stellt feste Kapazität pro Feature Train zur
Verfügung
• Das Team entscheidet wer an welchem Feature arbeitet
• 2 wöchige Iterationen mit queue replenishment, iteration
review und Retrospektive
• Definition of Done (DoD) für jeden Übergabepunkt
• Koordinierter Input vom Release - Management
• WIP limits pro Person (2 Magnete pro Person)
• WIP limits pro Swimlane (Limit pro Arbeitstyp)
• Express Lane um auf dringende Probleme reagieren zu können
• Externe Supportanfragen oder Fehler, die das LC Team nicht
alleine lösen kann
• Teaminterne Probleme/Deadlines

10. Team Board Elemente
10
WIP Limits pro Person
Commited
Backlog (nahe Zukunft)
Feature Train (swimlane)
DoD
Express Lane
WIP Limits pro Feature Train
und Arbeitstyp

11. Level UP - Value Stream Board (FL3)
11
Projekt / Initiative Level

12. Prozessdetails Projekt-Level
12
• Value-driven Process
• Verschiedene Phasen entlang der Kette werden von
unterschiedlichen Teams bearbeitet
• Übergabepunkte mit DoD „qualitätsgesichert“ um waste zu
vermeiden
• Ausrichtung am sensibelsten Teil der Kette
• In diesem Fall die Entwicklung und Akzeptanzphase, da hier
immer deutlich weniger Kapazität als Nachfrage

13. Projektboard Elemente
13
Input Queue
Arbeitstypen
Definition
of Done
Phasen
Team(s) die an Aufgabe arbeiten
werden mit Magnet dargestellt
(rot – extern)
VALUE STREAM

14. Level UP – Portfolio Level
14

15. Prozessdetails Portfolio
15
• Zeigt Art der Ressourcen (SW, HW, Prod, ...)
• Zuordnung von Initiativen (Projekten) zu Ressourcen
• Bietet Übersicht über aktuelle und zukünftig zugesagte Arbeiten
• Alles was nicht auf der Darstellung ist, ist nicht zugesagt
• Hat implizite WIP Limits
• Nicht mehr als 2 Initiativen/Projekte pro Ressource pro
Monat
• Mehr als 1 nur in Übergangsphasen
• Kommunikationsinstrument zu allen Stakeholdern der
Entwicklung
• Kein physikalisches Board (mehrere Standorte, mehrere
Organisationen)
• Monatliches Portfolio Meeting (15-20 Personen)
• Strenge Ablaufregeln, Moderation

16. Portfolio Board Elemente
16
Site/Team/Kapazität
Capabilities
Freie Kapazität
VerfügbareKapazitätEntwicklung
Zeitraum
Zukünftiges
Commitment
Nicht verfügbar

17. Vorher
17

18. Priorisierung per Cost of Delay
18
Auswahl, was als nächstes kommt...

19. PKE Electronics AG
PM, Entwicklung, Support, Techniker
Beispiel 2

20. PKE Produkte
20

21. • Entwicklung ca. 40 Mitarbeiter
• Entwickler, 2 Technische Redakteurinnen
• Test getrennt von Entwicklung, 2 Personen
im Support
• 2 Große “Teams”
• Arbeit nur im Push Verfahren (via Tool)
• Big Picture oft nicht bekannt
• Single Person Code “Ownership”
• Keine Automatisierten Tests, keine Unit Tests
• In einem Excel Sheet definierter
“Regressionstest”
Ausgangslage
21

22. • Test in Entwicklung integriert
• Aufgestockt auf 6 Personen
• Davon 3 Automatisierungsexperten
• Personen auf “Fachteams” aufgesplittet
• Freispielen der bisherigen Teamleads
• Eigentliche Aufgabe: Spezifikation und
Kommunikation mit PM
• Stabilisierungsphase und erste
grundlegende Refactorings um gröbste
Qualitätsprobleme einzudämmen
Grundlegende Änderungen
22

23. • Release immer vom “Development Main”
• In jedem Release unfertige Teile enthalten
• Qualität unklar (Test erst nach “Freigabe” an den
Support)
• Releasezyklen nicht vorhanden
• “On-Demand” für Projekterfordernisse
• “Quick Fixes”
• Viele “Bastelinstallationen”
• Viele Störungen durch Feldprobleme und
ungeplante dringende Projekterfordernisse
• 2 Monate “Sprints”
• Selten mehr als 50% des geplanten Umfanges
umgesetzt, Kommunikation erst bei Release
Release Politik “alt”
23

24. Release Politik “neu”
24
• Einführung Feature-Branches und Feature-Teams
• “Virtual Main” für Test und Integration
• Release immer von “Stable Branch”
• Service Releases enthalten nur Bugfixes, keine neuen
Funktionalitäten
• Qualität vorab prüfen (mit internem Test)
• Testautomatisierung einführen (Aufholbedarf!)
• Feste Releasezyklen eingeführt
• Alle 6 Monate ein Major Feature Release
• Jedes Monat ein Service Release für die letzten beiden Major
Releases
• Kapazität für Lifecycle und Projekterfordernisse reserviert,
ansonsten feste Roadmap auf Saga Ebene
• Development Slots pro Saga, mindestens MVP wird geliefert,
nice-to-haves nach Kapazität

25. Value Stream Analyse
25

26. Value Stream  Toolkette
26

27. Release Politik “neu” graphisch
27

28. Gesamte Entwicklung  Ein Board
28

29. Slot Abschätzung
29
• Magic Estimation
• MVP + Nice-To Haves
• Die Erfahrung wird den
“Scotty Factor” zeigen

30. Portfolio Board
30

31. • Messungen von Beginn an mit in/out
• Einfach durchzuführen
• Datumsstempel
• Einmal pro Woche in Excel übertragen
• Trend erkennbar
• Migration auf Tool im Laufen, Metriken
kommen danach mit mehr Detail von dort
• Excel-Tools von Troy Magennis
• https://github.com/FocusedObjective/FocusedObjective.Resources/tree/master/Spreadsheets
Messungen
31

32. Messungen (1)
32
0
20
40
60
80
100
120
140
5/16/2015 6/5/2015 6/25/2015 7/15/2015 8/4/2015 8/24/2015 9/13/2015 10/3/2015 10/23/2015 11/12/2015
CycleTimeinDays
Date item was completed
ITEM CYCLE TIME (IN CALENDAR DAYS)

33. Messungen (2)
33
Year-Week Number
Avg WIP Throughput Avg Cycle Time WIP Trend Throughput Trend Avg. Cycle Time Trend

34. Messungen (3)
34
28
68
86
136
146
170
177
174 175
189
166
141
137
124
108
112
87
74
32 32
18
2
1
28
68
86
136
147
168
156 158
154
137 136
124
105
97
83
69
28
23
15
2 0
0
20
40
60
80
100
120
140
160
180
200
Numberofin-progressitemsbyweek
Year-Week Number
Max WIP
Avg WIP
Min WIP
Linear (Avg WIP)

35. Messungen (4)
35
14
21
14 13
5
16
30
20
47
50
25
38
64
38
51
61
57
18
40
33
2
Countofcloseditemsduringweek
Year-Week Number

36. Messungen (5)
36
-28
-40
-18
-50
-10
-24
-3
12
-14
16
22
0
13
19
-2
24
12
43
-4
14
16
Year-Week Number
More started than completed
More completed than started

37. Messungen (6)
37
28
216
103
64
57
33
39
22 25
14 12
16
2
8 8 5 3 1 0 1
0.5 7 14 21 28 35 42 49 56 63 70 77 84 91 98 105 112 119 126 133
Countofitemswiththiscycletime
Cycle Time value (calendar days from start to complete)
CYCLE TIME HISTOGRAM

38. Messungen (7)
38
1.5
8 8
22
12
22
28
34
23
16
40
18
25
7 8
12 12
8 6.5
3
8.5
0
20
40
60
80
100
120
140
2015-
23
2015-
24
2015-
25
2015-
26
2015-
27
2015-
28
2015-
29
2015-
30
2015-
31
2015-
32
2015-
33
2015-
34
2015-
35
2015-
36
2015-
37
2015-
38
2015-
39
2015-
40
2015-
41
2015-
42
2015-
43
75th Percentile 5.75 10 14.5 26 28 29.5 39.5 37.5 41.5 42.75 53 50.5 48 21 15.5 42 34 20.75 17 5 9.75
Highest 7 15 19 27 29 41 49 54 64 70 75 77 93 91 94 105 114 97 129 58 11
Median 1.5 8 8 22 12 22 28 34 23 16 40 18 25 7 8 12 12 8 6.5 3 8.5
Lowest 1 0.5 0.5 1 0.5 3 2 6 1 1 0.5 0.5 0.5 0.5 0.5 0.5 1 0.5 0.5 0.5 6
25th Percentile 1 2 1 21 6 18 25 26.25 7 8.25 11 8.25 7.75 4 3.5 2 6 3.25 2.75 1 7.25
Cycletimeindays
Cycle time range for items completed within each week (year-week number)
Days to complete items (cycle time) by week

39. Messungen - Datenvalidierung
39
0
20
40
60
80
100
120
140
5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 55% 60% 65% 70% 75% 80% 85% 90% 95% 100%
Cycletimevalueindays
Percentile
Cycle time Actual vs Estimate Weibull Curve Fit
Estimated parameters - shape:0,79 scale:22,13
actual estimated

40. Kanban Board Support
40

41. Best Practices / Eindrücke
41

42. Best Practices / Eindrücke
42

43. Best Practices / Eindrücke
43

44. Best Practices / Eindrücke
44
• Immer Low-
Tech starten
• Pen&Paper
• Für ein Tool
entscheiden
wenn Prozess
im
Wesentlichen
gefestigt

45. Best Practices / Eindrücke
45

46. Best Practices / Eindrücke
46

47. PKE Electronics AG
Computerstraße 6
1100 Wien
T +43 (0) 50150-1021
pke.electronics@pke.at
www.pke.at
www.pke-de.com
www.pke-electronics.ch
www.tb-traxler.at