7 Arten der Verschwendung
Teilweise fertiggestellte Tasks
Dokumentation
Überflüssige Features
Kontextwechsel
Übergaben
Verzögerungen
Fehler
Muda: "...jede menschliche Aktivität, die Ressourcen verbraucht, 
                aber keinen Wert erzeugt"
angewandt auf Softwareentwicklung 
(in Anlehnung an Mary Poppendieck)
Mache Probleme 
sichtbar
Überproduktion
Bestände
Transport
Wartezeiten
Verschwendung im Prozess
Bewegung
Nacharbeiten und Fehler
Stabilität
Standardisierung
Heijunka
Eliminiere Verschwendung
Just In Time
Jidoka
Kontinuierlicher
Fluss
Taktzyklen
Pull-System
Stop The Line
Finde Fehler sofort
"Stop the Line"
Finde die Ursache für den Fehler
Experimentiere, um eine Lösung zu 
       finden
Implementiere die Lösung
"Start the Line"
Streben nach ständiger Verbesserung
Geschichte
Taiichi Ohno:
       Toyota Production System
Shigeo Shingo: 
       Study Of ‘Toyota’ Production System
Kaizen
Ziel: Höchste Qualität, niedrigste Kosten, geringste Durchlaufzeit
Die Fähigkeit eines Systems, sich beim Auftreten von Anomalitäten wie z.B. Fehlern, Qualitäts- oder Produktionsproblemen selbst abzuschalten
Harmonisierung des Produktionsflusses durch
Vermeidung von Warteschlangen, und dadurch
Liege- und Transportzeiten
Übertragen auf
Softwareentwicklung
Kaizen
Weitere Regeln können eingeführt werden
"Weniger ist mehr"
Bewährt:
Ähnlich Retrospektiven bei agilen Methoden
Finden in unregelmässigen Abständen statt
Stärkerer Fokus auf Objektivität durch Analyse von Daten aus der Vergangenheit
Teilnehmer nicht nur aus dem Entwicklungsteam, sondern der gesamten Organisation
Unterschiede
Probleme nicht verwalten, sondern lösen
Tägliche Statusmeetings
Operations Reviews
Root Cause Analysis
Beispiel: Tickets stauen sich vor einer Arbeitsstation
Visualisierung
Cumulative Flow Diagram (CFD)
Work in Progress
Durchsatz
Fehlerrate
Vergleichbar mit Burnup-Diagrammen bei Scrum und XP
Beispiel
Ticket
Ticket
Ticket
Ticket
Ticket
...
3 Regeln
Visualisiere den Workflow
Limitiere Work in Progress
Optimiere die Durchlaufzeiten
Kontinuierlicher Verbesserungsprozess ist 
fester Bestandteil, jedoch sind keine Praktiken 
fest vorgegeben.
Zeigt die Zustände an allen Stationen des Systems an
Durch das Kanban Board werden Probleme schnell sichtbar
Beispiel: Tickets stauen sich vor einer Arbeitsstation
Wann eignet sich Kanban?
Gefahren
Wenige Regeln und hohe Anpassungsfähigkeit ermöglichen zahlreiche Spielräume. Deswegen oft v.a. anfangs noch häufiger Anpassungsbedarf
Im Extremfall gleicht die Implementierung einem Wasserfallprozess
Bei gut verstandenen, repetitiven Prozessen (z.B. User Help Desk)
Bei schlechter Planbarkeit und Vorhersagbarkeit
Wenn es v.a. auf niedrige Durchlaufzeit ankommt (Bugfixes etc.)
Bei starker Arbeitsteilung und Generalisierung
Kanban kann oft einfacher einzuführen sein als das eher "kämpferische" Scrum
Weitere Informationen
Henrik Kniberg: Kanban vs Scrum
       http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
David J. Anderson: Kanban
       http://www.amazon.de/Kanban-David-J- 
      Anderson/dp/0984521402/ref=sr_1_1?ie=UTF8&s=books-
      intl-de&qid=1277377202&sr=8-1
Limited WIP Society
       http://www.limitedwipsociety.org/
Scrum vs Kanban
Ein Scrum Board entspricht einem Team
Ein Kanban Board kann beliebig verteilt werden