Die Kanban Methode für evolutionäre Change □ Portfolio Kanban □ Personal Kanban (for Teams) □ Lean Change □ Kanban für DevOps □ Shallow und Deep Kanban □ Scrumban ▪ Andere Arten von Kanban □ Klein-k kanban Systemen für WIP Limitierungen □ ERP Kanban □ NEU: OpenKanban 4 2013-10-02
what you do now □ Agree to pursue incremental, evolutionary change □ Initially, respect current roles, responsibilities & job titles □ Encourage acts of leadership at all levels in the organisation from individual contributors to senior management. (NEU) ▪ Praktiken □ Visualize □ Limit WIP □ Manage flow □ Make Management policies explicit □ Develop feedback mechanisms at the workflow, inter-workflow and organization level (NEU) □ Improve collaboratively using "Safe to fail“ experiments 5 2013-10-02
gesagt werden Kanban für Wartung, Scrum für Neuentwicklung Scrum ist für Neuentwicklung gemeint und weniger geeignet für Wartung. Kanban hat nichts mit Neuentwicklung oder Wartung zu tun. Es geht um Change, aber funktioniert gut zusammen mit Neuentwicklung oder Wartungsprozessen. Kanban ist Scrum-Lite, oder Scrum ohne Iterationen und Planung Kanban hat ein Konzept „Cadence“. Planung hängt von dem tatsächlichen Prozess ab. Kanban hat auch viele Elemente, die Scrum nicht hat Kanban ist besser geeignet für Firmen, die mit Scrum Schwierigkeiten haben Eine schwaches Kanban-System kann vielleicht zunächst weniger Auswirkung auf einem Team haben als Scrum, aber wenn Kanban konsequent angewendet wird, wird wahrscheinlich mehr Disziplin und Leadership benötigt als bei Scrum Du kannst von Scrum nach Kanban wechseln Du kannst Kanban auf einem Prozess anwenden in dem Scrum vorkommt und vielleicht nach eine Reihe von kleinen Änderungen zu einem Prozess kommen, der nicht mehr als Scrum gilt 6 2013-10-02
2013-10-02 Scrum Kanban Framework oder Basis für Produktentwicklungsprozess Methode zur Unterstützung der evolutionären Verbesserung Iterationen Flow Nur die Produktentwicklung selbst Ganze Wertschöpfungskette Board folgt unterschiedliche Aufgaben über einen generischen „Do“ Schritt Board folgt Einträge von Kundenwert über eine Reihe von spezifischen Schritten „Walled Garden“ / Einzelteam Wirkung nicht lokal-isoliert „Revolutionär“ „Evolutionär“ Möglich von Null anzufangen Braucht einen bestehenden Prozess Hilft ein Team besser Produkte zu entwickeln Kann Organisationen helfen Verbesserungen überall zu identifizieren
Scrum und Kanban sind also nicht austauschbare Alternativen ▪ Sie haben andere Ziele, Voraussetzungen und Einsatzgebiete ▪ Ein Vergleich hilft Scrum-Kennern, Kanban zu verstehen ▪ Beide haben Regeln ▪ Beide ändern die Arbeitsweise ein bisschen, und sorgen für ständige Verbesserung 8 2013-10-02
SIND 9 2013-10-02 Scrum Kanban Standups geht durch die Runde geht über das Board Teams klein und funktionsübergreifend kann mehrere Teams und Teilnehmer involvieren Retrospektive pflicht optional. Operations Review auch optional. Verbesserungen jederzeit möglich Backlog / Optionen soll geordnet werden, typisch geschätzt muss nicht geordnet werden, typisch nicht geschätzt Items PBIs können Stories sein aber müssen nicht. Tasks gibt es auch PBIs, Stories, Minimal Marketable Features, Business Value Increments…
der Toleranz bzgl. Kosten/Verlusten und der Dauer bis sie zurück bezahlt sind ▪ Kaikaku: Eine größere, radikale, revolutionäre Change ▪ Kaizen: Eine Reihe von kleine Verbesserungen 11 2013-10-02
selbst □ WIP Limits □ Classes of Service □ Swimlanes □ Spalten ▪ Angehen der Symptome von Problemen □ Engpässe □ alte/vergessene/stillstehende Arbeitspakete ▪ Der tatsächliche Prozess wird geändert. Z.B.: □ Angebote werden anders geschrieben □ Management-Rolle anders definiert □ Unnötige Prozessschritte werden abgeschafft 13 2013-10-02
müssen bereit sein Ownership des Systems zu übernehmen und zu verteilen ▪ Alle müssen offen sein ihre Arbeits- und Denkweise schrittweise anzupassen ▪ Einiges kann schwer fallen: □ Aspekte oder Konsequenzen von Kanban (wie Slack und Swarming) zu akzeptieren □ Wenn die Nachfrage größer ist als die Kapazität, müssen Anfragen absagt werden □ Termine usw. dürfen nicht mehr auf Wünschen basieren, sondern auf Realität, weil unrealistischer Druck keine Option sein wird ▪ Ein Risiko besteht Change in der falschen Richtung zu fördern! 18 2013-10-02
Woche □ Gleich wie in Scrum Velocity, (aber eine einfache Anzahl statt Summe von Story Points) □ Anzahl von Items die das System verlässt pro Zeiteinheit □ Schwer zu verbessern, dennoch möglich durch: Mehr Kapazität Reduzierung von verschwendeter Arbeit Effektivere Arbeitsweise □ Wegen Pull-Prinzip: sollte gleich wie die Eingaberate und gleich für alle Spalten sein ▪ Lead Time □ z.B. 30 Tage □ Zeit zwischen erstem Commitment und Done (es gibt aber Ausnahmen) □ Pro Item oder Durchschnitt (pro Class of Service) □ Leichter zu verbessern durch Reduzierung der WIP (bis zu einem Punkt) □ Kann auch durch die Entfernen der Wartezeiten der Arbeit reduziert werden □ Gut zu reduzieren weil Wissensarbeit „sauer wie Milch“ wird 19 2013-10-02
90 Items □ Anzahl von Items im System (oder in einer Auswahl von Spalten) □ Sollen normalerweise reduziert werden um Lead Time zu optimieren □ Manchmal zum bestimmten Zeitpunkt oder als Durchschnitt benutzt □ Kann reduziert werden durch Reduzierung der WIP Limits ▪ Andere □ „Cycle Time“ □ Process Cycle Efficiency □ Pull-Transaktionen pro Mitarbeiter (oder pro Euro) 20 2013-10-02
konstant bleibt, sollte eine Reduzierung der WIP die Lead Time reduzieren ▪ Kann benutzt werden um die WIP Limits zu berechnen ▪ Kann benutzt werden um Lead Times zu schätzen ohne Messungen zu haben ▪ Wenn Lead Time bekannt ist und ein bestimmter Throughput benötigt wird um eine bekannte Anzahl von Items zu einem Termin erledigt zu bekommen, dann kann die benötigte WIP Kapazität berechnet werden 21 2013-10-02
konstant bleibt, sollte eine Reduzierung der WIP die Lead Time reduzieren ▪ Throughput = 5 Items pro Tag ▪ Aktuelles WIP = 90 Items (Durchschnitt) ▪ Berechnete durchschnittliche Lead Time = 90 / 5 = 18 Tagen ▪ Wir reduzieren WIP auf 80 Items (Durchschnitt) ▪ Neue durchschnittliche Lead Time = 80 / 5 = 16 Tagen 22 2013-10-02
um die WIP Limits zu berechnen ▪ Throughput = 5 Items pro Tag ▪ Items soll maximal 2 Tagen in der Entwicklung dauern ▪ WIP Limit = 5 * 2 = 10 Items ▪ Aber: □ Vielleicht nicht die beste Strategie! □ Nur um eine grobe Idee zu geben! □ Nicht vergessen: die WIP Limits decken aber auch die Wartespalte des nächsten Schritts ab! 23 2013-10-02
um Lead Times zu schätzen ohne Messungen zu haben ▪ Throughput = 5 Items pro Woche ▪ Aktuelles WIP = 90 Items ▪ Geschätzte durchschnittliche Lead Time = 90 / 5 = 18 Wochen 24 2013-10-02
bekannt ist und ein bestimmter Throughput benötigt wird um eine bekannte Anzahl von Items zu einem Termin erledigt zu bekommen, dann kann die benötigte WIP Kapazität berechnet werden ▪ Lead Time = 30 Tagen ▪ Backlog hat 50 Items ▪ Freigabe muss in 100 Tagen geliefert werden ▪ Benötigte Throughput = 50 / (100-30) = 0,71 Items pro Tag ▪ Benötigtes WIP = 30 * 0,71 = 22 Items ▪ => Minimal 22 von den Items am Board sollen zu diesem Produkt gehören um den Liefertermin zu schaffen 25 2013-10-02
bis untern ▪ Vertikaler Abstand ist WIP ▪ Horizontale Abstand zwischen 2 Farben ist Lead Time ▪ Anstieg ist Throughput ▪ Diese Diagramme zeigt kein Flow an => typisch wenn: □ Wasserfall-Prozess □ Batch-Size ziemlich groß □ Zu viel WIP □ Viel Overhead, Verschwendung und/oder Batching. □ Zu viel hin-und-her bis jemand entschiedet ob etwas fertig ist oder nicht ▪ Die Senke geht um ein verschwundenes Board ;-) ▪ Die letzte 2 Monate zeigen einen Fokuswechsel an, aber keine richtige Änderung 27 2013-10-02
es Flow, weil keine Bürokratie, kein Overhead, kleine Items, kein Wasserfall-Prozess. Karten verschieben wenn es fertig ist ohne Diskussion. Wenn doch nicht fertig, kommt eine neue Karte. ▪ Ende Mai zeigt viele Items in Produktion in einem Rutsch Kunde installiert neue Version
von Items mit festen Termin werden innerhalb von 45 Tagen geliefert werden ▪ Aber: 99% von Items mit festen Termin werden innerhalb von 300 Tagen geliefert werden ▪ Weil Lead Times nicht normalverteilt sind, können Standard-Abweichung usw. nicht benutzt werden um SLAs zu berechnen
können unterschiedliche Regeln haben ▪ Die 4 Klassiker (auf Verzögerungskosten basiert) □ Beschleunigt (Expedite) □ Fester Termin (Fixed Date) □ Vage (Intangible) □ Standard ▪ Classes of Services können Kapazität (WIP) allokiert bekommen ▪ Können durch Kartenfarbe oder mit Swimlanes identifiziert werden ▪ Können auch unterschiedliche Pull-Regeln haben 33 2013-10-02
noch Geld um neue Entwicklung und Wartung von alten Produkten zu finanzieren ▪ Technisch: Viele neue Technologien sind nicht in einem Rutsch ▪ Kulturelle: Jede Team bekommt eine gute Mischung von Neuentwicklung und Wartung ▪ Fokus: Wir verteilen und nicht zu dünn über zu viele Produkten ▪ Kapazität für Innovation: Ein komplettes Team ist frei (aber verteilt durch alle Teams) um schnell um neue spannende Möglichkeiten anzugehen
Wir wollen auch ein Bilanz haben zwischen Cash Cows, strategische Produkte, risikoreiche Produkte, und interne Forschung ▪ Risk Management Regeln auf der Team-Ebene: 10% von jedem Teams WIP soll für Technical Debt allokiert, n% für Produkt A, n% für Produkt B ▪ Diese Schrauben können ständig angepasst werden nach der Situation ▪ Jedes Team hat andere Profile (Throughput, Lead Time, Vorhersehbarkeit, Kosten usw.), was ermöglicht Management das beste Team auszuwählen für die Arbeit.
genug an“ ▪ Aber wie lange wird‘s dauern? □ Littles Law: nur für einzelne Karten nützlich (aber kann benutzt werden um benötigte WIP zu berechnen) □ Grobe Formel: (Anzahl von Items / Throughput) + durchschnittliche Lead Time □ (50 Items / 0,5 Items pro Tag) + 30 Tage = 130 Tage □ Aber wegen Variabilität, Projektdauer hängt von 1 oder 2 schwere Items ab □ Wie lang haben die letzte 50 Items gedauert? (Letztes „Done“ Datum – frühestens „Start“ Datum) = 250 Tage. (Wegen eine Karte die besonders lang gedauert hat) ▪ Projekte sind überwertet!
pro Stunde @ 81% : 10 Items pro Stunde @ 83% : 10 Items pro Stunde @ 45% : 10 Items pro Stunde @ 87% : 10 Items pro Stunde Image Attribution: Joseph William Zaehnsdorf [Public domain], via Wikimedia Commons
▪ Effizienz = Wert / Aufwand ▪ Managers arbeiten als ob Effizienz = Wert * Aufwand! ▪ Time & Materials Billing eignet sich auch als ob mehr Aufwand besser ist! ▪ Unnötige Wissensarbeit besonders Verschwenderisch weil es verderblich ist ▪ Wissensarbeit ist kein Vermögen bis es Live und Validiert ist, sondern eine Liability (Belastung?) ▪ Arbeit die zu früh ausgeführt ist, ist auch Verschwendung ▪ Lieber ein Buch lesen oder Facebook anschauen als „für das nächste Item vorbereiten“
Kanban hat sogenannte „2-Phase Commitment“ ▪ Phase 1: Pull von Backlog in Input Queue „Wir commiten das Item anzufangen, und vorhersehen mit m% (nicht sehr viel) Sicherheit das es wird in n Tagen fertig“ ▪ Phase 2: Später im Prozess, nach der meisten Arbeit: „Wir commiten das Item abzuschließen und vorhersehen mit m% (viel mehr) Sicherheit das es wird in n Tagen fertig“ ▪ Jedes Pull bietet die Möglichkeit an ein Entscheidungen zu treffen: □ Was soll ich pullen? □ Soll ich etwas entfernen? Weil Optionen haben Wert weil die Zukunft unsicher ist □ Wenn keine Ideen weggeworfen werden, es heißt die Zukunft 100% sicher ist ▪ Liquidität: Anzahl von „Pull-Transaktionen“ pro Mitarbeiter (oder pro Euro)
nur Änderung in einer beliebigen Richtung ▪ Aber hilft etwas besonderes zu passieren ▪ High Trust Culture ▪ „Deep Kanban - A biased and opinionated participant in the path towards synergy“ ▪ Kanban geht vielleicht nicht nur um Change, aber auch die Ergebnis davon
viele Möglichkeiten, aber The Lean-Kanban University (LKU) bietet eine „accredited“ 2-tagige Schulung an ▪ Wird von Accredited Kanban Trainers (AKT) angeboten ▪ Also erste Zertifizierung (AKT) nur für Trainers bei LKU Partner-Firmen ▪ Zweite Stufe wäre 3-tagige Kanban Masterclass nur von David Anderson angeboten ▪ Neue Zertifizierung für Coaches verfügbar: Kanban Coaching Professional (KCP) □ In Masterclass teilgenommen □ Erfahrung □ „Peer-Review“ □ Bisher nur 34 davon
Jahr gibt es mehrere Lean-Kanban Konferenzen die von der Lean Systems Society und/oder die Lean-Kanban-University organisiert sind ▪ Lean Kanban Central Europe: http://www.lean-kanban.eu/ ▪ Usergroup: Limited WIP Society: http://limitedwipsociety.ning.com/ ▪ Limited WIP Society DE: https://www.xing.com/net/pri1f31bbx/limitedwipsocietygermany/ ▪ Mailing List kanbandev: http://finance.groups.yahoo.com/group/kanbandev/
kurt_haeusler
gakkenleap
so_kotani
matsuritechnologies
campfire
syo
nishimuraryuma
wed
attelu
mabhr
buyselltechnologies
takeuchigroup
trinitytechnology
searls
mongodb
thekraken
geeforr
addyosmani
brad_frost
robhawkes
cassininazir
holman
scottboms
smashingmag
