Lean and Agile Coffee Nov. 2015

581 Aufrufe

Veröffentlicht am

Slides from my Lean and Agile Coffee presentation in Vienna

Veröffentlicht in: Leadership & Management
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
581
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
16
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Lean and Agile Coffee Nov. 2015

  1. 1. Lean & Agile Coffee Vienna Anwenderbeispiel Kanban Flight Levels Michael Rumpler Leiter Entwicklung PKE Electronics AG
  2. 2. Kanban Flight Levels 2
  3. 3. KABA MIC AWM Rümlang, Wetzikon (CH) Leonberg, Villingen-Schwenningen (DE) Entwicklung (HW, SW, Produktion) Produktion (Mechanik, Mechatronik, Elektronik) Beispiel 1
  4. 4. Beispiel Kaba MIC AWM 5 Produktmanagement Produktmanagement Produktmanagement Quality Assurance Project Management / Requirements Eng. Die Entwicklungsorganisation (vereinfacht)
  5. 5. 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
  6. 6. Schritt 1: Team-Zusammenlegung 7 12 Entwickler 4 Tester 2 Techn. Redakteure 3 POs 3 PMs
  7. 7. Team Level 8
  8. 8. 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
  9. 9. 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
  10. 10. Level UP - Value Stream Board (FL3) 11 Projekt / Initiative Level
  11. 11. 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
  12. 12. Projektboard Elemente 13 Input Queue Arbeitstypen Definition of Done Phasen Team(s) die an Aufgabe arbeiten werden mit Magnet dargestellt (rot – extern) VALUE STREAM
  13. 13. Level UP – Portfolio Level 14
  14. 14. 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
  15. 15. Portfolio Board Elemente 16 Site/Team/Kapazität Capabilities Freie Kapazität VerfügbareKapazitätEntwicklung Zeitraum Zukünftiges Commitment Nicht verfügbar
  16. 16. Vorher 17
  17. 17. Priorisierung per Cost of Delay 18 Auswahl, was als nächstes kommt...
  18. 18. PKE Electronics AG PM, Entwicklung, Support, Techniker Beispiel 2
  19. 19. PKE Produkte 20
  20. 20. • 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
  21. 21. • 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
  22. 22. • 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
  23. 23. 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
  24. 24. Value Stream Analyse 25
  25. 25. Value Stream  Toolkette 26
  26. 26. Release Politik “neu” graphisch 27
  27. 27. Gesamte Entwicklung  Ein Board 28
  28. 28. Slot Abschätzung 29 • Magic Estimation • MVP + Nice-To Haves • Die Erfahrung wird den “Scotty Factor” zeigen
  29. 29. Portfolio Board 30
  30. 30. • 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
  31. 31. 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)
  32. 32. Messungen (2) 33 Year-Week Number Avg WIP Throughput Avg Cycle Time WIP Trend Throughput Trend Avg. Cycle Time Trend
  33. 33. 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)
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. Kanban Board Support 40
  40. 40. Best Practices / Eindrücke 41
  41. 41. Best Practices / Eindrücke 42
  42. 42. Best Practices / Eindrücke 43
  43. 43. Best Practices / Eindrücke 44 • Immer Low- Tech starten • Pen&Paper • Für ein Tool entscheiden wenn Prozess im Wesentlichen gefestigt
  44. 44. Best Practices / Eindrücke 45
  45. 45. Best Practices / Eindrücke 46
  46. 46. 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

×