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

Weitere ähnliche Inhalte

Andere mochten auch

Experiences on scaling agile
Experiences on scaling agileExperiences on scaling agile
Experiences on scaling agile
Jens Wilke
 
Portfolio Kanban - Low-Friction Method to Improve Organization's Effectiveness
Portfolio Kanban - Low-Friction Method to Improve Organization's EffectivenessPortfolio Kanban - Low-Friction Method to Improve Organization's Effectiveness
Portfolio Kanban - Low-Friction Method to Improve Organization's Effectiveness
Pawel Brodzinski
 
Hierarchical kanban boards in action - Ignite talk at Lean Kanban North Ameri...
Hierarchical kanban boards in action - Ignite talk at Lean Kanban North Ameri...Hierarchical kanban boards in action - Ignite talk at Lean Kanban North Ameri...
Hierarchical kanban boards in action - Ignite talk at Lean Kanban North Ameri...
Yuval Yeret
 
Scrumban - Projektentwicklung mit Scrum und Incident-Management über Kanban m...
Scrumban - Projektentwicklung mit Scrum und Incident-Management über Kanban m...Scrumban - Projektentwicklung mit Scrum und Incident-Management über Kanban m...
Scrumban - Projektentwicklung mit Scrum und Incident-Management über Kanban m...
Cem Kulac
 
Kanban for Software Development and Kaizen Culture
Kanban for Software Development and Kaizen CultureKanban for Software Development and Kaizen Culture
Kanban for Software Development and Kaizen Culture
Acquate
 
The evils of multi-tasking and how personal Kanban can help you
The evils of multi-tasking and how personal Kanban can help you The evils of multi-tasking and how personal Kanban can help you
The evils of multi-tasking and how personal Kanban can help you
Sandy Mamoli
 
Production scheduling boards - November 2016
Production scheduling boards - November 2016Production scheduling boards - November 2016
Production scheduling boards - November 2016
W3 Group Canada Inc.
 
Portfolio Kanban - Seeing the Big Picture
Portfolio Kanban - Seeing the Big Picture Portfolio Kanban - Seeing the Big Picture
Portfolio Kanban - Seeing the Big Picture
Sandy Mamoli
 
Kanban Portfolio Management, a real case.
Kanban Portfolio Management, a real case.Kanban Portfolio Management, a real case.
Kanban Portfolio Management, a real case.
Giulio Roggero
 
Kanban for Portfolio Management
Kanban for Portfolio ManagementKanban for Portfolio Management
Kanban for Portfolio Management
Gaetano Mazzanti
 
Portfolio for JIRA & Kanban: How Thrillist Manages Their Product Roadmap
Portfolio for JIRA & Kanban: How Thrillist Manages Their Product RoadmapPortfolio for JIRA & Kanban: How Thrillist Manages Their Product Roadmap
Portfolio for JIRA & Kanban: How Thrillist Manages Their Product Roadmap
Atlassian
 
The Three Things You Need to Know to Transform Any Size Organization Into an ...
The Three Things You Need to Know to Transform Any Size Organization Into an ...The Three Things You Need to Know to Transform Any Size Organization Into an ...
The Three Things You Need to Know to Transform Any Size Organization Into an ...
Mike Cottmeyer
 
Introduction to Kanban for Creative Agencies
Introduction to Kanban for Creative AgenciesIntroduction to Kanban for Creative Agencies
Introduction to Kanban for Creative Agencies
William Evans
 
Why agile is failing in large enterprises
Why agile is failing in large enterprisesWhy agile is failing in large enterprises
Why agile is failing in large enterprises
LeadingAgile
 
The Executives Guide
The Executives GuideThe Executives Guide
The Executives Guide
Mike Cottmeyer
 
Kanban, Lean, and Scrum
Kanban, Lean, and ScrumKanban, Lean, and Scrum
Kanban, Lean, and ScrumThomas Moedl
 
Lean Project Management Principles
Lean Project Management Principles Lean Project Management Principles
Lean Project Management Principles
Ryder System, Inc.
 
Kanban simulation @ 46. agile monday
Kanban simulation @ 46. agile mondayKanban simulation @ 46. agile monday
Kanban simulation @ 46. agile monday
Martin Heider
 

Andere mochten auch (18)

Experiences on scaling agile
Experiences on scaling agileExperiences on scaling agile
Experiences on scaling agile
 
Portfolio Kanban - Low-Friction Method to Improve Organization's Effectiveness
Portfolio Kanban - Low-Friction Method to Improve Organization's EffectivenessPortfolio Kanban - Low-Friction Method to Improve Organization's Effectiveness
Portfolio Kanban - Low-Friction Method to Improve Organization's Effectiveness
 
Hierarchical kanban boards in action - Ignite talk at Lean Kanban North Ameri...
Hierarchical kanban boards in action - Ignite talk at Lean Kanban North Ameri...Hierarchical kanban boards in action - Ignite talk at Lean Kanban North Ameri...
Hierarchical kanban boards in action - Ignite talk at Lean Kanban North Ameri...
 
Scrumban - Projektentwicklung mit Scrum und Incident-Management über Kanban m...
Scrumban - Projektentwicklung mit Scrum und Incident-Management über Kanban m...Scrumban - Projektentwicklung mit Scrum und Incident-Management über Kanban m...
Scrumban - Projektentwicklung mit Scrum und Incident-Management über Kanban m...
 
Kanban for Software Development and Kaizen Culture
Kanban for Software Development and Kaizen CultureKanban for Software Development and Kaizen Culture
Kanban for Software Development and Kaizen Culture
 
The evils of multi-tasking and how personal Kanban can help you
The evils of multi-tasking and how personal Kanban can help you The evils of multi-tasking and how personal Kanban can help you
The evils of multi-tasking and how personal Kanban can help you
 
Production scheduling boards - November 2016
Production scheduling boards - November 2016Production scheduling boards - November 2016
Production scheduling boards - November 2016
 
Portfolio Kanban - Seeing the Big Picture
Portfolio Kanban - Seeing the Big Picture Portfolio Kanban - Seeing the Big Picture
Portfolio Kanban - Seeing the Big Picture
 
Kanban Portfolio Management, a real case.
Kanban Portfolio Management, a real case.Kanban Portfolio Management, a real case.
Kanban Portfolio Management, a real case.
 
Kanban for Portfolio Management
Kanban for Portfolio ManagementKanban for Portfolio Management
Kanban for Portfolio Management
 
Portfolio for JIRA & Kanban: How Thrillist Manages Their Product Roadmap
Portfolio for JIRA & Kanban: How Thrillist Manages Their Product RoadmapPortfolio for JIRA & Kanban: How Thrillist Manages Their Product Roadmap
Portfolio for JIRA & Kanban: How Thrillist Manages Their Product Roadmap
 
The Three Things You Need to Know to Transform Any Size Organization Into an ...
The Three Things You Need to Know to Transform Any Size Organization Into an ...The Three Things You Need to Know to Transform Any Size Organization Into an ...
The Three Things You Need to Know to Transform Any Size Organization Into an ...
 
Introduction to Kanban for Creative Agencies
Introduction to Kanban for Creative AgenciesIntroduction to Kanban for Creative Agencies
Introduction to Kanban for Creative Agencies
 
Why agile is failing in large enterprises
Why agile is failing in large enterprisesWhy agile is failing in large enterprises
Why agile is failing in large enterprises
 
The Executives Guide
The Executives GuideThe Executives Guide
The Executives Guide
 
Kanban, Lean, and Scrum
Kanban, Lean, and ScrumKanban, Lean, and Scrum
Kanban, Lean, and Scrum
 
Lean Project Management Principles
Lean Project Management Principles Lean Project Management Principles
Lean Project Management Principles
 
Kanban simulation @ 46. agile monday
Kanban simulation @ 46. agile mondayKanban simulation @ 46. agile monday
Kanban simulation @ 46. agile monday
 

Ähnlich wie Lean and Agile Coffee Nov. 2015

Metrics we can gain from our (Kanban) system and what we can learn from ..
Metrics we can gain from our (Kanban) system and what we can learn from .. Metrics we can gain from our (Kanban) system and what we can learn from ..
Metrics we can gain from our (Kanban) system and what we can learn from ..
Martin Putz
 
DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
QAware GmbH
 
Mit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managenMit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managen
Christoph Schmiedinger
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungChristian Baranowski
 
Die Success Driver Analyse (SDA) als wirksames Instrument zur Steuerung von k...
Die Success Driver Analyse (SDA) als wirksames Instrument zur Steuerung von k...Die Success Driver Analyse (SDA) als wirksames Instrument zur Steuerung von k...
Die Success Driver Analyse (SDA) als wirksames Instrument zur Steuerung von k...
Ernest Wallmueller
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Fabian Niesen
 
Continous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickelnContinous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickeln
Martin Seibert
 
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Torsten Kleiber
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
René Spengler
 
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
Tobias Schlüter
 
SCD13: Agile Entwicklung bei der shopware AG
SCD13: Agile Entwicklung bei der shopware AGSCD13: Agile Entwicklung bei der shopware AG
SCD13: Agile Entwicklung bei der shopware AG
shopware AG
 
Hilfe! Agile und die Digitale Transformation haben meinen Job gefressen ...
Hilfe! Agile und die Digitale Transformation haben meinen Job gefressen ...Hilfe! Agile und die Digitale Transformation haben meinen Job gefressen ...
Hilfe! Agile und die Digitale Transformation haben meinen Job gefressen ...
inovex GmbH
 
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
Sascha Böhr
 
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
 
7 Schritte der FMEA
7 Schritte der FMEA7 Schritte der FMEA
7 Schritte der FMEA
KVP Institut GmbH
 
Deployments Best Practices
Deployments Best PracticesDeployments Best Practices
Deployments Best Practices
Daniel Drexlmaier
 
OOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger eweOOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger ewe
Markus Theilen
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Marc Bless
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
SwissQ Consulting AG
 
EInführung in Lean Forecasting
EInführung in Lean ForecastingEInführung in Lean Forecasting
EInführung in Lean Forecasting
Susanne Bartel
 

Ähnlich wie Lean and Agile Coffee Nov. 2015 (20)

Metrics we can gain from our (Kanban) system and what we can learn from ..
Metrics we can gain from our (Kanban) system and what we can learn from .. Metrics we can gain from our (Kanban) system and what we can learn from ..
Metrics we can gain from our (Kanban) system and what we can learn from ..
 
DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
 
Mit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managenMit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managen
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software Entwicklung
 
Die Success Driver Analyse (SDA) als wirksames Instrument zur Steuerung von k...
Die Success Driver Analyse (SDA) als wirksames Instrument zur Steuerung von k...Die Success Driver Analyse (SDA) als wirksames Instrument zur Steuerung von k...
Die Success Driver Analyse (SDA) als wirksames Instrument zur Steuerung von k...
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
 
Continous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickelnContinous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickeln
 
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
 
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
 
SCD13: Agile Entwicklung bei der shopware AG
SCD13: Agile Entwicklung bei der shopware AGSCD13: Agile Entwicklung bei der shopware AG
SCD13: Agile Entwicklung bei der shopware AG
 
Hilfe! Agile und die Digitale Transformation haben meinen Job gefressen ...
Hilfe! Agile und die Digitale Transformation haben meinen Job gefressen ...Hilfe! Agile und die Digitale Transformation haben meinen Job gefressen ...
Hilfe! Agile und die Digitale Transformation haben meinen Job gefressen ...
 
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
 
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)
 
7 Schritte der FMEA
7 Schritte der FMEA7 Schritte der FMEA
7 Schritte der FMEA
 
Deployments Best Practices
Deployments Best PracticesDeployments Best Practices
Deployments Best Practices
 
OOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger eweOOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger ewe
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
 
EInführung in Lean Forecasting
EInführung in Lean ForecastingEInführung in Lean Forecasting
EInführung in Lean Forecasting
 

Lean and Agile Coffee Nov. 2015

  • 1. Lean & Agile Coffee Vienna Anwenderbeispiel Kanban Flight Levels Michael Rumpler Leiter Entwicklung PKE Electronics AG
  • 3. KABA MIC AWM Rümlang, Wetzikon (CH) Leonberg, Villingen-Schwenningen (DE) Entwicklung (HW, SW, Produktion) Produktion (Mechanik, Mechatronik, Elektronik) Beispiel 1
  • 4.
  • 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
  • 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
  • 18. Priorisierung per Cost of Delay 18 Auswahl, was als nächstes kommt...
  • 19. PKE Electronics AG PM, Entwicklung, Support, Techniker Beispiel 2
  • 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
  • 26. Value Stream  Toolkette 26
  • 28. Gesamte Entwicklung  Ein Board 28
  • 29. Slot Abschätzung 29 • Magic Estimation • MVP + Nice-To Haves • Die Erfahrung wird den “Scotty Factor” zeigen
  • 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)
  • 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
  • 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