Lean Forecasting @ Limited WIP Society Hamburg 13. September 2016
Susanne Bartel Agile Coach, Kanban Coach & Trainer
http://flow.hamburg
Inhalt
• Teil 1 • Einführung: Was ist Lean Forecasting / Beyond
Estimation? • Kleine Statistik-Auffrischung :)
• Teil 2 • Lego Flow Game (und kurze Pause)
• Teil 3 • Konkrete Fragestellungen - Theorie und Praxis
1. Wie lange dauert die Umsetzung von Anforderungen?
2. Wann ist das erwartete Projektende? 3. Weiterführende Fragen
Wie machen das die Wetterfrösche?
Basierend auf Beobachtungen und historischen Daten,
mit Modellen die die örtlichen Bedingungen wiedergeben,
sagen sie potentielle Wetterereignisse vorher
…. und die wahrscheinlichsten seht ihr im Wetterbericht.
Häufig schwache Korrelation zwischen Story Points und Aufwand oder Durchlaufzeit
Hohe Aufwände für Schätzungen und Planungen
Vielfach durch Studien belegt, wie schlecht wir im Schätzen in der Software-
Industrie sind.
0,00#
5,00#
10,00#
15,00#
20,00#
25,00#
30,00#
35,00#
40,00#
0# 1# 2# 3# 4# 5# 6#
Story&Points&zu&Lead&1me&[d]&
Lead#.me#[d]#
Faktor: 0,3
1,0$
10,0$
100,0$
1000,0$
10000,0$
0$ 2$ 4$ 6$ 8$ 10$ 12$ 14$ 16$
Aufwand$(Stunden)$ Linear$(Aufwand$(Stunden))$ Linear$(Aufwand$(Stunden))$
Faktor:0,36
Beispiel-Korrelationen
0"
20"
40"
60"
80"
100"
120"
0" 1" 2" 3" 4" 5" 6"
Story&Punkte&zu&Aufwand& Faktor:0,2
Lean / „Probabilistic“ Forecasting
Projektion historischer Daten in die Zukunft zur Beantwortung planerischer Fragen
Unter Beachtung von Wahrscheinlichkeiten
Unter Nutzung von Modellen
„Klassische“ Planung:Schätzen zukünftiger Ereignisse
Vorteile
Wahrscheinlichkeitsbasierte Prognosen: • Schnell • Billig • Zuverlässig • Entlasten die „echt“ wertschöpfenden
Mitglieder im Team
Monte Carlo Simulation
• Ein stochastisches Verfahren
• Sehr häufig durchgeführte Zufallsexperimente
• Häufig genutzt zur Nachbildung komplexer Prozesse
Übung „Bereiche“
Teilt euch in 3 Gruppen auf. Bestimmt einen Würfler, dieser darf die Würfel den anderen nicht zeigen.
Die Situation
Ihr nehmt Stichproben, um einen Bereich zu ermitteln. D.h. wir suchen die MIN und MAX Werte
Schritt 2
Sortiert die Zahlen nach ihrer Größe. Mit welcher % liegt die vierte Zahl in diesem Bereich?
Schritt 4
Vergleicht euer MIN und MAX mit den tatsächlichen Werten anhand der Würfel. Beobachtungen?
Vorhersagewahr-scheinlichkeit abhängig von Probenzahl
(Keine Duplikate, gleich verteilt, zufällige Proben)
Anzahl vorhandener Proben
Wahrscheinlichkeit, dass nächste Probe innerhalb des Bereichs
liegt
3 50 %
4 67 %5 75 %
6 80 %
7 83 %8 86 %
9 88 %
10 89 %11 90 %
12 91 %13 92 %
14 92 %
15 93 %16 93 %
17 94 %
18 94 %19 94 %
20 95 %
Die benötigte Stichprobengröße ist deutlich kleiner als wir denken
Wahrscheinlichkeit = 1- 1k −1
⎛⎝⎜
⎞⎠⎟
*100
German Tanks (oder auch iPhones)
Monat Statistische Schätzung
Geheimdienst- Schätzung
Deutsche Aufzeichnungen
Juni 1940 169 1.000 122
Juni 1941 244 1.550 271
August 1942 327 1.550 342
–Troy Magennis
„Wenn ein Messwert sich über die Zeit ändert oder bei jeder Messung anders ist, ist es eine Verteilung.“
VERTEILUNG (DISTRIBUTION)
–Troy Magennis
„Prognosen sind Antworten auf Fragen zu Ereignissen, die noch nicht eingetreten sind.“
PROGNOSE (Forecast)
Durchlaufzeit, „Lead Time“
• In Kanban: Die Zeitdauer, in der eine Anforderung von der ersten limitierten Spalte („Zusagepunkt“) bis zur letzten Spalte „wandert“
• Lego Flow: Beginn „Liefern“ bis zur erfolgreichen Abnahme
• Differenz zwischen 2 Zeitstempeln
• In Software-Entwicklungs-Teams typischerweise Start der Implementierung bis „Done“ oder Release
Beispiel: Durchlaufzeiten-Verteilung in Lego Flow Game Beobachtungen?
00:30:00$ 01:00:00$ 01:30:00$ 02:00:00$ 02:30:00$ 03:00:00$ 03:30:00$ 04:00:00$ 04:30:00$ 05:00:00$ 03:40:00$00:00:00$ 00:30:00$ 01:00:00$ 01:30:00$ 02:00:00$ 02:30:00$ 03:00:00$ 03:30:00$ 04:00:00$ 04:30:00$ 05:00:00$
SUMME$ 1$ 5$ 5$ 4$ 8$ 5$ 2$ 3$ 1$ 1$ 0$
0$
1$
2$
3$
4$
5$
6$
7$
8$
9$
Lego%Flow%Lead%Times%Histogramm%
Frage
• Wie sieht eine typische Verteilung von Durchlaufzeiten in Software-Entwicklungsprojekten aus?
• Und wie bei IT Operations Teams?
Weibull Lead Time Verteilungen
Typische Verteilungen in SW-Projekten (Magennis) siehe auch Lead Time Forecasting Cards von Alexei Zheglov
Mode: an was sich Leute gut erinnern (Achtung! üblicherweise nur 18-28% Wahrscheinlichkeit!)
Median: zur kontinuierlichenÜberprüfung des
Vorhersage-Modells
Control Limit: für SLA’s
80% percentile: 4 von 5 Items dauern max. so lange -> Planung
Durchschnitt: üblicherweise über dem Median (bis zu 50% kleinerin Operations)
Weibull Lead Time Verteilungen
Typische Verteilungen in SW-Projekten (Magennis)siehe auch Lead Time Forecasting Cards von Alexei Zheglov
Voraussetzungen
• Stabiles System - wir glauben die Verteilung der Anforderungen bleibt in etwa stabil
• In der Verteilung gibt es nur eine „Spitze“ (Modus, engl. mode)
Praktische Tipps
Durchlaufzeit = Differenz zweier Zeitstempel
Auf physischen Boards: Datumsstempel benutzen
Excel: Histogramme über den Umweg von Klassen bauen: Intervalle bilden, ZÄHLENWENN()
Wert Percen(le10% 1:19
20% 1:46
30% 2:03
40% 2:12
50% 2:25
60% 2:44
70% 2:57
80% 3:24
90% 3:52
100% 4:51
1. Werte sortieren
1:22
2:21
3:05
4:51
3:45
2:29
1:12
3:38
1:55
2:58
2:56
0:57
1:12
1:22
1:41
1:55
2:03
2:11
2:13
2:21
2:29
2:41
2:56
2:58
3:05
3:38
3:45
4:10
4:51
Berechnung von „Percentile“ (Perzentil, Quantil)
=QUANTIL(Bereich;%Wert)
Beispiele
0"
1"
2"
3"
4"
5"
6"
7"
8"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Bugs%&%Stories%(addi0v)%
Bugs"
Durchlaufzeit (Tage von/bis)
Anza
hl V
orko
mm
en
0"
1"
2"
3"
4"
5"
6"
7"
8"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Bugs%&%Stories%(addi0v)%
Bugs"
Durchlaufzeit
Anza
hl
Beispiele
0"
1"
2"
3"
4"
5"
6"
7"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Anzahl'Vorko
mmen
'
Lead'Time'in'Tagen'
Bugs'
Bugs"
0"
1"
2"
3"
4"
5"
6"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Anzahl'Vorko
mmen
'
Lead'0me'in'Tagen'
Stories'
Stories"
Recap: Durchlaufzeiten-Prognose
• Erlaubt die Prognose auf z.B. Story- oder Task-Ebene
• Vorteile: • Leicht zu sammelnde Messwerte • Nutzt historische Daten (komplett oder Stichproben) • Folgt bekannten Verteilungsmustern
• Nutzen: Zusagen für einzelne Anforderungen. Termingerechter Start der Implementierung. Analyse (z.B. Ausreißer etc.). Basis für weitere Berechnungen.
Beispiel: Projektdauer
Projektdauer= Anzahl der Anforderungen(*)
Durchsatz
Wir haben Daten über den Durchsatz unseres Teams „P“:7, 8, 2, 11, 7, 12 Anforderungen pro Woche. Wann werden die verbleibenden 100 Anforderungen umgesetzt sein?
Projektdauer =100 Anforderungen
7 Anforderungen / Woche
Projektdauer = 100 Wochen / 7
Projektdauer = 15 Wochen
16,70% 12
33,40% 11
50,10% 8
66,80% 7
83,50% 7
100,20% 2
Achtung! Umgekehrte Reihenfolge
(*) Batch Size ungerundet: 14,2 Wochen
Praktische TippsTrick: Durchsatz aus z.B. Jira:=KALENDERWOCHE(DateClosed)dann pivotieren oder Zählenwenn()
Troy Magennis’ Sheet für Monte Carlo Throughput Forecasting:
http://focusedobjective.com/free-tools-resources/
S-CurveQuelle: Project Planning using Little's Law (Dimitar Bakardzhiev)
Wieviel Kapazität für welchen Arbeitstyp?
Wie hoch ist der Durchsatz?
Auswirkungen von Verbesserungen der Durchlaufzeit
Wie viele Teams brauchen wir?
Was wir benötigen
1. Lead Time Verteilung:
• Ist bekannt
• Single Mode - in Klassen unterteilt (s.u.)
• Wir glauben die Verteilung bleibt stabil
2. Anforderungen sind identifiziert und klassifiziert
• Langfristig stabile Durchschnittswerte! • Voraussetzungen:
• Durchschnittliche Output-Rate = durchschnittliche Input-Rate • Alle angefangene Arbeit wird schließlich beendet und verlässt das System • Die Menge angefangener Arbeit sollte zu Beginn und Ende des gewählten
Zeitintervalls etwa gleich sein • Die durchschnittliche Menge angefangener Arbeit (WIP) ist stabil • In der Berechnung müssen konsistente Einheiten genutzt werden
• siehe auch „Little’s Flaw“ (Daniel Vacanti)
Little’s Law
Lieferrate = WIPDurchlaufzeit throughput = WIP
lead time
Das klingt ja cool, und nu?
• Mess-Strecke für die Lead Time definieren
• Datenschätze heben! (Durchsatz, Lead Times). All you need is:
• Eintrittsdatum
• Austrittsdatum
• Fertiggestellte Menge je Zeiteinheit (z.B. Wochen)
• Excel anschmeißen, auch mit Troy’s Tools
• …oder Actionable Agile
Brauche ich dazu ein Kanban-System?
• Jein. All diese Techniken können auch von „klassischen“ oder Scrum-Teams angewendet werden. Siehe jedoch Voraussetzungen.
• Story Points in mathematischen Gleichungen ?!
• Aber: Ein Kanban-System kann helfen, die Vorhersagegenauigkeit (predictability) zu verbessern: • Verschiedene Arbeitstypen / Serviceklassen, um mehrere
Modes zu vermeiden • Ist Hilfsmittel für kontinuierliche Verbesserung
(Zuverlässigkeit, Durchsatz, etc.)
Kontinuierliche Anpassung, aktives Steuern
Prognose erstellen
Modell aufstellen / anpassen
Kontinuierliche Überprüfung der Gültigkeit des Modells mit Anpassung der Vorhersage— ermöglicht aktives Steuern!
Überprüfung der Hypothesen
historischeDaten
Danke für eure Aufmerksamkeit!
Susanne Bartel [email protected]
Twitter @projectzone
http://flow.hamburg
nach Karl Scotland, http://availagility.co.uk/lego-flow-game/
LEGO FLOW GAME
Euer Ziel
• Setzt so viele Lego-Figuren wie möglich anhand der Anleitung zusammen und liefert sie!
• In der gegebenen Reihenfolge
• Arbeitet als Team zusammen
Analysieren
1. Finde die richtige Tür.
2. Nimm eine Karteikarte.
3. Schreibe die Nummer der Tür auf die Karte.
4. Lege die Tür auf die Karte, Instruktionen oben.
Beschaffen
1. Notiere die Zeit.
2. Finde das Beutelchen mit den passenden Teilen.
3. Hefte es mit der Büroklammer an die Tür.
Prüfen
1. Überprüfe dass die Figur • GENAU dem Bild entspricht • ROBUST ist
2. Wenn ja, dann akzeptiere • Notiere die Zeit! • LIEFERE zum Marktplatz!
3. Wenn nicht, zurück an die entsprechende Station
Manager
1. Auf die Zeit achten
2. Auf die Prozesseinhaltung achten
3. Daten sammeln 1. Wie viele Figuren je Status in progress? 2. Zählen und alle 30s aufschreiben
Manager
00:30 01:00 01:30 2:00 2:30 3:00 3:30 4:00 4:30 5:00 5:30 6:00
Analysis 2 1
Supply 3 2
Build 5 6
Accept 1 2
Done 2 4
Alle 30s zählen je Arbeitsstation
„Done“ sollte niemals weniger werden, muss
ansteigen
Flussbasierte Arbeit
• Besprecht euch als Team.
• Markiert eure Arbeitsstationen
• Ihr arbeitet kontinuierlich, wir unterbrechen gelegentlich für Systemverbesserungen (Inspect & Adapt)
• Start!
5 min Timebox
Debrief Lego Flow
• Beobachtungen? Überraschungen?
• Seid ihr „in den Fluss“ gekommen? Wann?
• Begriffe: • Durchlaufzeit (lead time)
• WIP (Work In Progress)
• Durchsatz (throughput)
Lego Flow, Ergebnisse Durchlauf 1Team:
00:30 01:00 01:30 2:00 2:30 3:00 3:30 4:00 4:30 5:00 5:30 6:00
Analyse 3 2 5 6 4 2 2 1 2 2 2 2
Beschaffen 2 1 1 1 2 1 1 1 1 0 0 1
Bauen 2 0 1 2 4 5 6 7 8 8 5
Prüfen 1 0 2 0 0 0 0 0
Fertig 1 1 2 2 3 3 3 3 6
WIP 5 5 7 9 9 9 12 11 13 13 13 14Lieferrate 0 0 0 1 0 1 0 1 0 0 0 3
Lego Flow, Ergebnisse Durchlauf 2Team: Durchlauf:
00:30 01:00 01:30 2:00 2:30 3:00 3:30 4:00 4:30 5:00 5:30 6:00
Analyse 5 1 1 1 0 1
Beschaffen 3 2 2 2 2 2 0 0 1 1
Bauen 2 3 2 4 3 3 2 3 5 4 3
Prüfen & Ausliefern 1 1 1 1
Fertig 1 2 3 4 6 7 10
WIP 5 2 7 5 7 6 8 8 8 12 13 14Lieferrate 0 0 0 0 0 1 1 1 1 2 1 3
CFDs
0
2
4
6
8
10
12
14
16
00:30 01:00 01:30 2:00 2:30 3:00 3:30 4:00 4:30 5:00 5:30 6:00
Stü
ckza
hl
Durchlauf 2
Fertig Prüfen & Ausliefern Bauen Beschaffen Analyse
0
4
8
12
16 Durchlauf 1
Analyse
Beschaffen
Bauen
Prüfen
Fertig
Verbesserung
im zweiten Lauf!
Credits und Referenzen
• Basiert auf der Arbeit von Troy Magennis, David J. Anderson, Alexei Zheglov, and Dan Brown in diesem Bereich. Siehe auch deren Blogs.
• German Tanks: http://www.spiegel.de/wissenschaft/mensch/rechentrick-der-alliierten-wie-seriennummern-die-nazi-industrie-verrieten-a-728211.html
• Für mehr:
• Twitter: #noestimates
• noestimatesbook.com
• Blogs of the above
• Limited WIP Society
Bilder
• Würfel: https://www.flickr.com/photos/dskley/6196133034 • fliegende Würfel: https://www.flickr.com/photos/dskley/6195620885 • Pause: <a href="https://www.flickr.com/photos/finklez/3059185823"
title="Pause - השהיה by Eran Finkle, on Flickr"><img src="https://farm4.staticflickr.com/3190/3059185823_ce8570bdd2_s.jpg" width="75" height="75" alt="Pause - השהיה“></a>
• Wall: https://www.flickr.com/photos/dg_pics/3937990893/ • Umbrella: https://www.flickr.com/photos/dskley/9666364180 • Fragezeichen: https://www.flickr.com/photos/eleaf/2536358399 • Mind the gap: https://www.flickr.com/photos/simone_brunozzi/
2643200238/ • Easy: https://www.flickr.com/photos/catharticflux/2484317019/ • Monkey bento: https://www.flickr.com/photos/buzzymelibee/8598689804
Flusseffizienz
Flusseffizienz = Arbeitszeit(Arbeitszeit +Wartezeit)
Story&/&Feature&Incep0on&5&Days&
Wai0ng&in&Backlog&25&days&
System&Regression&Tes0ng&&&Staging&&5&Days&
Wai0ng&for&Release&Window&5&Days&
“Ac0ve&Development”&30&days&To
tal&Cycle&Tim
e&
Pa.ern:&Total&Cycle&Time&In Software- Entwicklungs- Projekten liegt die Flusseffizienz in der Regel bei max. 15%-20%.