11. Treffen der Limited WIP Society Cologne

Schon vor Beginn des Treffens (Anmeldung per Doodle) standen drei spannende Themen auf dem Programm:

• Die Vorstellung einer Kanban Simulation
  geschrieben von @Keinze in NetLogo und online im Internet aufrufbar kann man hier ein Kanban-System simulieren und das Verhalten der einzelnen Akteure in der Simulation programmatisch ändern
• Bei „Sag Nein zu monotonen Retrospektiven“
  geht es um praktische Erfahrungen mit Methoden, Techniken und Elementen die in Retrospektiven angewandt werden können
• In der Runde Alltägliche Fragen aus dem Kanban/Lean/Agilen Alltag
  schließlich dreht sich alles um aktuellen Fragen, die die Teilnehmer grade in Projekten beschäftigen

Und so entwickelte sich dann auch der Abend:

Diskussion zu Davids „Erweiterung“ von Kanban

In der tat spannend war die lokale Diskussion zu Davids Plänen, zwei weitere Praktiken in die Definition von Software-Kanban aufzunehmen.

Einige der Inhalte finden sich natürlich auch auf der kanbandev Mailingliste bei Yahoo wieder, besonders haben wir den Aspekt der Abstraktion betrachtet.

Auch 2 der bisherigen 5 Praktiken lassen sich unter die ursprünglichen 3 Praktiken integrieren.

Die neuen Praktiken erschienen der Runde weitestgehend bereits durch die bisherigen Praktiken abgedeckt oder aus dem Bereich Kaizen zu kommen. Der Detaillierungsgrad scheint durch die neuen Praktiken immer feiner zu werden – ob das wirklich die Wahrscheinlichkeit einer erfolgreichen Software-Kanban-Implementierung erhöht, wurde zumindest bezweifelt.

Anm. MM: Und auch David schrieb ja heute (11.5.2012) grade auf der kanbandev Mailingliste zum Thema Leadership

„Ich will es ganz deutlich machen: Ich füge nichts neues hinzu. Ich mache nur etwas ausdrücklich, das schon immer da war[…] Ich habe durch empirische Ergebnisse gelernt, das ich einige Dinge ausdrücklicher darstellen musste um die Ergebnisse herbei zu führen, die ich erwartete“

Zu „manage flow“…

… wurde noch gefragt, ob es sich dabei im Prinzip um die Sichtweise handelt, die in Scum-Teams der Scrum-Master oft einnimmt. oder um es anders zu formulieren:

Ist Management des Flows == entfernen von Impediments?

Nachdem wir uns dann noch mal an Davids Artikel zu den Praktiken gerieben hatten, herrschte (meiner Erinnerung nach -MM) aber relative Einigkeit darüber, dass nicht nur dieser Aspekt gemeint ist, sondern vielmehr auch die Konzentration auf messbare Größen des Durchflusses durch das System. Hierzu kam auch in der späteren Diskussion (s.u) zu der Notwendigkeit eines Zieles für eine Kanban Initiative noch mal ein (zumindest für mich -MM) spannender Denkanstoß.

Wieviel Ziel braucht ein Kanban System

Die Situation: Einer der Sponsoren eines (mit Kanban operierenden) Teams bat den Coach darum, das Team „besser zu machen“ – ohne zu spezifizieren, was denn besser ist.

Nach wenigen Monaten Kanban sanken Lead- und Cycle-Time erheblich und alle waren glücklich.

Alle?

Bei genauerem Hinterfragen stellte der Coach fest, dass dem eigentlich gar nicht so war – vielmehr war für die meisten diese Verbesserung entweder nicht wahrnehmbar, oder unwichtig.

Somit stellte sich die Frage nach den Zielen des Kanban Einsatzes – und von wo diese Ziele kommen können.

Einer der entscheidenden Punkte aus der Diskussion war eine Referenz zum Systems Thinking:

Systems Thinking sagt, bevor man etwas verbessern kann muss man erstmal identifizieren, wo das Verbesserungspotential liegt.

Zudem muss man sich überlegen, was denn bei Kanban überhaupt gemessen wird.

Eine der Ideen, die aus dem üblichen Software-Kanban „by teh Book“ heraus gehen war die Idee

Wie wäre es mit anderen Elementen als Work-Items? Z.B. 2 Stunden Timeboxes für „Beliebig“ (In denen getan werden kann, was immer man für sinnvoll hält) um neue Messungen zu ermöglichen (z.B. Erhöhung der Zufriedenen Kunden)

Was hat Kanban mit Kaizen zu tun?

Da in mehreren Diskussionen Kaizen und Kaizen-Momente als Hinweise genannt wurden, ist jetzt eine der Karten, die für das nächste Mal gezogen werden können ein Vortrag zum Thema Kaizen – derzeit von mir, aber ich kann mir auch gut eine Co-Produktion vorstellen… Interesse?

Sag Nein zu monotonen Retrospektiven

Obwohl die meisten Retrospektiven mehr oder weniger deutlich den fünf Phasen aus dem modernen Klassiker „Agile Retrospectives„, kurz zusammengefasst bei Slideshare, folgen, können Retrospektiven auf Dauer monoton werden. Obwohl Websites wie das Agile Retrospective Wiki oder Esther Derbys Ressourcensammlung viele unterschiedliche Anregungen geben, bleibt ein erheblicher Unterschied zwischen Theorie und Praxis.

Die in der Runde praktisch bekannten Methoden liessen sich wie folgt den fünf Phasen zuordnen, die größte Herausforderung scheint „Phase IV“ zu bleiben –

Ankommen

• Weather Report
• Arbeitsvereinbarungen treffen
• z.B. „Ein Automodell“ z.B. zur Charakterisierung des letzten Sprints

Daten Sammeln

• Timeline
• Mood Chart
• Hypothesen
• glad/sad/mad
• z.B. Unterschiedliche Kartenfarben
• z.B. Spektrum auf einem Tisch von (glad bis sad)

Erkenntnisse generieren

• 5 Whys
• Cause-Effect Diagram (Systems Thinking)
• Fishbone Diagramm

Maßnahmen ableiten

• Ideas
• Open Item List inkl. Signup

Abschluss

• Appreciates
• ROTI
• Feedback Door

Bemerkenswert …

… fanden wir auch Corinnas Projekt, das uns Sergey vorstellte, den Retr-O-Mat, mit dem man sehr elegant die unterschiedlichen Techniken für die einzelnen Phasen zusammenstellen (lassen) kann.

Kanban Simulation

Um wirklich festzustellen, welchen Effekt die Beschränkung der Work in Progress hat, hat Mirko Blüming @keinze vor einiger Zeit bereits eine beeindruckende Simulation geschrieben, mit der sich die Effekte von WIP-Limits und anderen Parametern eines Projektes einfach untersuchen lassen.

Abgesehen von der Simulation selber waren wir alle auch beeindruckt von der Mächtigkeit der Simulationssprache NetLogo, die uns von Mirko als eine sehr effiziente (und noch dazu kostenfreie) Möglichkeit Simulationen zu erstellen vorgestellt wurde.

Mirko plant, noch den Link zu der Online-Version seiner Simulation an die Mailingliste zu schicken und vielleicht sogar den Quellcode der Simulation als Open Source Projekt zur Verfügung zu stellen.

(und wenn ich (-MM) das Video von der Präsentation halbwegs vernünftig bearbeitet bekomme, gibt es die Vorstellung der Simulation demnächst sogar noch zum download für diejenigen, die nicht live dabei sein konnten).