In letzter Zeit schwappt die “Lean”-Welle aus der Fertigung in die Softwareentwicklung herüber. Begriffe wie Kanban, WIP-Limit, Lead Time, Varianz, Durchsatz kommen auch bei uns Entwicklern und unseren Managern in Mode. Heißt das, wir messen, kontrollieren und takten unsere Arbeit wie im Zeitraffer? Es wird Zeit, sich von gängigen Missverständnissen zu trennen und auf dem Teppich zu bleiben.
Lean Development = Überdrehter Motor in der Entwicklung?
1. Lean Development = Übertunter
Motor in der Entwicklung?
Matthias Bohlen
mbohlen@mbohlen.de
@mbohlende
http://www.mbohlen.de
2. Matthias Bohlen : Coach für
effektive Produktentwicklung
Werthaltiges Produkt für den Kunden "Matthias ist
ein genialer
Hohe Motivation und Produktivität der Teams Team- und
Management-
Geringe Fluktuation der Mitarbeiter flüsterer.
Das Team hier
Entlastung für Executives in der Entwicklung gehört zu den
angenehmsten
Mit gleichem Einsatz mehr erreichen Arbeitsumge-
bungen, die es
Freude an der Arbeit haben gibt."
2
3. Agile - der Stand der Dinge
• Gestern • Heute • Morgen
XP ist jetzt Scrum ist Lean und
der Alltag, soeben Kanban
richtig? Mainstream kommen
geworden gerade zur
Tür herein
3
4. Das Pendel der Naivität schwingt
• 1995 Software- • 2003 Wir
Entwicklung ist formalisieren sie
eine Kunst und eben doch!
nicht formali- (Architektur, MDA,
sierbar (XP, TDD) software factories)
• 2008 Es klappt • 2011 Wir
nicht, also ist formalisieren jetzt
Entwicklung doch doch wieder,
eine Kunst indem wir messen
(Software und reagieren
Craftsmanship) (Lean/Kanban für
Naive)
4
5. Lean in der Fertigung
1850
Eli Whitney
austauschbare Teile
Frederick Taylor
Standardisierte Arbeit,
1900 "Taylorismus"
Henry Ford
Fließband, Fertigungsstrategie
W. Edwards Deming
1950 Qualitätsmanagement
Taiichi Ohno, Shigeo Shingo
Toyota Production System
2000 5
7. Lean in der Entwicklung
1990
Managing the Design Factory
Don Reinertsen
Lean Software Kanban
Development
Mary Poppendieck David Anderson
Kanban-Implementierung
bei der BBC
David Joyce ...und viele andere!
2010 7
8. Lean-Denkprinzipien
1. Eliminiere Verschwendung
2. Verbessere Lernprozesse
3. Verzögere Entscheidungen
4. Liefere schnell
5. Baue Integrität ein
6. Ermächtige das Team
7. Sieh immer das Ganze!
Nach Mary Poppendieck
9. Das Modell hinter Kanban
Fünf Kerneigenschaften
• Visualisiere den Workflow
• Limitiere angefangene Arbeit (WIP)
• Messe und manage den Fluss
• Mache Prozessrichtlinien explizit
• Benutze Modelle*, um Möglichkeiten zur
Verbesserung zu erkennen
* Modelle wie z.B. ToC = Theory of Constraints
11. Warnung: Naive Implementierungen
• Es tauchen die ersten naiven
Implementierungen von Lean/Kanban auf
• Zunächst durchaus korrekt und intelligent
• nach einigen Monaten absurd
11
12. Beispiel: Waterfall-ban
die gibt man an
ein...
zerlegt man in
Ein großes Fachkonzept Features
Monate lang
sammelt man, und dann: Kanban-Entwicklungsteam
Ha, das fertige
Produkt ist da!
Fehler meldet man dann am
en bloc geht das an... ...das Testteam! Schluss an das geduldige... 12
14. Wie konnte es so weit kommen?
• Management stellte anfänglich keine
Akzeptanztester zur Verfügung
• Entwicklungsteam arbeitete weiter
• Niemand hat gesehen, dass das auch bis
zum Ende des ersten Releases so bleiben
würde
• Entwicklungsteam gab auf und benannte
aus lauter Verzweiflung die letzte Spalte der
Kanban-Tafel um (von "done" auf "ready for
acceptance test") 14
15. Was hätte man tun können?
2 6 2 s t
Selected Elaboration Development Acceptance ie w
e vTest Done! f o ra c c .te
r nal R e ad y
I n te R
• Sobald klar war, dass die letzte Spalte nicht mehr
"done" heißt, hätte sie ein WIP-Limit bekommen
müssen.
• Das WIP-Limit hätte die Chance zur kulturellen
Veränderung gebracht.
• Am besten: Reaktion auf Erreichen des WIP-Limits
sofort bei Start des Projektes mit dem Management
vereinbaren.
15
16. Weiter aus dem Wasserfall...
• Konzepte-Schreiber: Konzepte verkleinern
• Tester: Früher einsetzen, kleinere
Portionen testen
• Ergebnis: Das Gesamtsystem würde
gewinnen, weil schnelleres Feedback die
Kosten senkt und die Qualität steigert.
16
17. Warum nicht?
• Auf große
Konzepte
verzichten
• Gleich mit
Feature-Listen
starten
17
18. Das System definiert die
Performance
95% der Performance einer
Organisation geht auf ihr System
zurück. Nur 5% kann man auf die
Individuen zurückführen.
W. Edwards Deming:
"The 95/5 rule".
18
19. System
• Eine Sammlung von Elementen, die
untereinander in Beziehung stehen und
miteinander wechselwirken.
• Beispiel: Eine Firma ist ein System aus
Menschen, Maschinen, Information,
Wissen, Beziehungen, Vorschriften,
Prozessen, Geld, usw.
19
20. Beispiel: Auf großem Fuße
• Kunde: "Der ist aber schön! Haben
Sie den auch in Größe 47?"
• Verkäuferin: "Nein, wir werden zwar
oft gefragt, aber wir haben das Modell
nur bis Größe 46."
• Kunde: "Wie kommt's?"
• Verkäuferin: "Weiß ich leider nicht,
das macht unser Einkauf!"
• Das Individuum würde ja gerne, aber
das System lässt es nicht zu.
20
21. Warum ist Veränderung so schwer?
• Wie viel Arbeit kommt herein?
e e!
• Wie viele Leute habe ich?
t s
e i
• Wie lange brauchen die Leute pro
l t e
Aufgabe?
a w
r k
• Können wir den Termin halten?
e n
• Aktivität bedeutet Kosten
V e
• Also: Je weniger Zeit pro Aktivität,
desto weniger Kosten.
D
21
22. Traditionelles Management =
Massenproduktion
• Arbeit standardisieren
e e n !
t
• Aktivitätszeiten reduzieren
e m
l
a at h
• Verschwendung
austreiben
r n
e ß
V a
• Lean ist scheinbar die
Antwort auf bekannte
M
Probleme!
22
23. Neue Fragen stellen
2011
• Wie viel Wert haben wir für den Kunden
geschaffen?
• Können wir schon (wieder) releasen?
• Sind wir ein System, das Variabilität
absorbieren kann?
• Können wir auch bei Änderung der
Rahmenbedingungen erfolgreich bleiben?
23
24. Neue Denkweisen und
Maßnahmen
2011
• Die Kosten liegen nicht in der Aktivität, sondern in
der Verknüpfung zwischen den Aktivitäten (Flow-
Gedanke).
• Geh zum Gemba (Ort des Geschehens)
• Studiere, ob/wie die Arbeit arbeitet
• Konzentriere Dich auf die Beziehungen der
Systemelemente, dann folgen die Finanzen
automatisch
• Probleme im System identifizieren und lösen - das
erzeugt finanziellen Erfolg als Nebenprodukt
24
25. Flow
• Kontinuierlicher Fluss von Wert
• Ausbalancierter Zustand
der menschlichen Psyche
• Hohes RoI und
angenehmes Arbeiten
25
26. Verlässlichkeit
• Kunde häufig in die Arbeit einbeziehen
• Geteilte Verantwortung für die Ergebnisse
• Trennung in "Kunde hier" und
"Dienstleister da" eher kontraproduktiv
26
27. Unsicherheit
• Produktentwicklung ist
immer unsicher
• Wer Sicherheit will, muss auf
Innovation verzichten
• Deshalb: Erwarte
Unsicherheit und passe Dein
Handeln entsprechend an!
27
28. • Menschen erzeugen den Wert in der
Produktentwicklung
Kreativität
• Bereite eine Umgebung für sie, in der sie
einen Unterschied machen können. 28
29. Performance
• Gemeinsame Zuständigkeit für die
Ergebnisse
• Geteilte Verantwortung dafür, dass das
Team effektiv ist
• Das stärkt die Team-Performance.
29
30. Wirksam und verlässlich
• Mit Hilfe von Strategien,
Prozessen und
Praktiken, die der
Situation angepasst sind
• Keine vorgefertigten
Ansätze aus der
Packung.
30
31. Wir sind alle Gärtner
• Manager züchten Teams.
• Teams züchten Software.
31
32. Ich helfe Ihnen dabei!
• Matthias Bohlen
• Coach für effektive Produktentwicklung
• mbohlen@mbohlen.de
• http://www.mbohlen.de/
• +49 170 772 8545