(Software-)Kanban zur kontinuierlichen Verbesserung (Vortrag)

Die PMI Agile Community of Practice Hamburg traf sich am 8. Oktober 2013 zum Vortragsabend beim Gastgeber it-agile in der Großen Elbstraße.

Kurz nach 18 Uhr trudelten die ersten Teilnehmer ein. Den Vortrag hatten
wir für 19 Uhr angesetzt. Und so blieb trotz des ungewohnt großen
Kreises noch gut Zeit für persönliches Kennenlernen untereinander, was
uns ja wichtig ist.

„STOP starting, START finishing!“

Arne, alias ‚Justin‘ mit der roten Krawatte, hat sich in seinem
Einführungsvortrag zu Software-Kanban auf das Einleiten von Kaizen bzw.
‚Kontinuierlichen Verbesserungsprozessen‘ fokussiert. Darum machte er zu
Beginn nochmal deutlich, dass Veränderungen üblicherweise zunächst für
Produktivitätseinbrüche sorgen, schließlich muß man sich an neue
Abläufe, Verfahren, Rollen oder was auch immer, erst einmal gewöhnen.
Dieses Phänomen drückt sich in der ‚J-curve‘ (wikipedia) aus.

Arne-Kanban_J-curve
aus der Präsentation von Dr. Arne Roock

(Ergänzung von mir: Kanban ist eine Methode des Lean Management und
steht im Grundsatz für das „Pull-Prinzip“, z.B. im Toyota Production
System.)
Zwar ist es manchmal unausweichlich, große Veränderung revolutionär, in
Transformationssprüngen anzugehen, z.B. in tiefen Krisensituationen.

Kanban-Evolucion
Aus Präsentation von Dr. Arne Roock: Evolucion.

Doch ist es grundsätzlich erstrebenswert, große Krisen zu vermeiden, durch ständige, kleinere Anpassungen an unser (Markt-)Umfeld,
ähnlich der Giraffe in der Savanne oder dem Eisbär in der Arktis.
Da kann es dann auch mal eine Fehlentwicklung, einen Fehlversuch geben, doch deren Auswirkungen sind nicht so dramatisch. Dafür ist Kanban gut  geeignet.

Grundprinzipien des Software Kanban

  1. Beginne dort, wo du dich im Moment befindest
  2. Einige dich mit Anderen auf evolutionäre Änderungen
  3. Respektiere bestehende Rollen, Prozesse, Verantworlichkeiten
  4. Sorge für Leadership

Diese Prinzipien wurden von einem der weltenweiten Verfechter des
Software-Kanban, also Kanban für Wissensarbeit, David Anderson
identifiziert.

Nützliche Software-Kanban Praktiken nach Andersen und ‚Justin‘

  1. Visualisieren
  2. Limitieren
  3. Durchfluß messen und managen
  4. Gemeinsame Regeln explizit machen
  5. Feedback-Zyklen installieren
  6. Modelle verwenden, um sich gemeinsam zu verbessern

Wie starten wir?

An einer Tafel zeichnen wir mindestens die Spalten „Aufgabenspeicher“,
„Aufgaben in Arbeit“, „Erledigt“. Besser aber, wir bilden in den Spalten unsere derzeitigen Arbeitsstationen des gelebten Prozesses ab. Dann bekommen wir einen
ersten Einblick, wo sich wieviele Aufgaben befinden, bzw. vielleicht sogar schon stauen oder mit schlechter Qualität hängen bleiben.

Aufgaben, die an einer der Stationen, aus welchen Gründen auch immer,
nicht weiter bearbeitet werden können, erhalten einen Erläuterungs-Aufkleber. Justin nennt das die „Masern“. Kinderkrankheiten.

Sowohl die Arbeits- und Effizienzforschung (Reduktion von Multitasking),
als auch die Warteschlangentheorie (hier: „Little’s Law„) haben gezeigt,
dass Dinge bzw. Aufgaben schneller zum Ziel kommen, wenn sauber
priorisiert möglichst einzeln in der Schlange stehen. So kamen die WIP
(= Work in progress) Limits zustande. Little’s Law besagt, dass die
durchschnittliche Durchlaufzeit einer Aufgabe ein Quotient von
durchschnittlicher Anzahl der Aufgaben in Arbeit und durchschnittlichem
Durchsatz ist.

Little's Law visuell
aus: Präsentation von Dr. Arne Roock

Mit den Zahlen über den Spalten definieren wir also, wieviele Aufgaben
maximal in einem Prozessschritt in Arbeit sein dürfen, um ihren
Durchfluß aufrecht zu erhalten. Stockt das System dennoch an einer
Stelle, ist – frei nach dem ‚Rechts-vor-links-Prinzip – mit höchster
Priorität dafür zu sorgen, dass die ruckelnde Aufgabe wieder in Fluß kommt.
Ein Tester wird also mit defekten Aufgaben nicht allein auf dem Flaschenhals sitzen gelassen, sondern sofort mit korrigierenden Maßnahmen unterstützt. Entwickler, die nicht daran beteiligt sind, aber dennoch keine weiteren erledigten Aufgaben in die ‚Test‘-Spalte schieben dürfen, haben nun ‚Leerlauf‘ (Slacktime).

Warum Leerlauf besser ist, als ständige Verstopfung

Dieser Leerlauf ist nicht schlecht. Im Gegenteil, wir brauchen ihn sogar: denn Innovation und somit auch Veränderungen, Verbesserungen am bestehen System entstehen ja meist erst in dem Moment, wo wir zurücktreten, unsere Perspektive wechseln und einfach Zeit haben, neue Ideen zu haben und auszuprobieren oder auch ein fettes Problem (Verstopfung) lösen müssen.

Das wiederum verbessert unsere Qualität und die Zeit, die das Produkt braucht, um fehlerfrei beim Kunden anzukommen.

Jetzt kommt auch das Pull-Prinzip zum Tragen: dadurch, dass die Beteiligten sich die nächsten anstehende Aufgabe zur Bearbeitung nehmen, statt schlimmstenfalls ständig von Projektmanagern mit dem Bombardement neuer Anforderungen unterbrochen zu werden, reguliert sich das System zum großen Teil selbst und bleibt … in Fluß.

Gegenüber Scrum, den meisten Anwesenden als agiles PM-Rahmenwerk bekannt, hat (Software-)Kanban den großen Vorteil, dass man nicht gleich die Organisation und deren Rollen komplett umkrempeln muß. Zudem ist es sehr passend auch in Umgebungen, die nicht projektorientiert arbeiten, also sowohl im Betrieb von Systemen, als auch im Management, Vertrieb und Marketing, etc.

Wer tiefer in das Thema einsteigen möchte, kann dies mit den weltweiten Koryphäen des Themas tun auf der jährlichen ‚Lean Kanban CE‘ Konferenz Anfang November, die in 2013 in Hamburg statfindet: http://www.lkce13.com/

Teilt Eure Erfahrungen auch gern hier via Kommentar mit uns.

Literaturhinweise aus ‚Justins‘ Unterlagen

Kanban.  David Anderson
Kaizen.  Masaaki Imai
Agile Projekte mit Scrum, XP, Kanban. Hg. Henning Wolf
Kanban in der IT. Klaus Leopold und Siegfried Kaltenecker
http://www.limitedwipsociety.org
http://www.software-kanban.de

Weitere interessante Links:

LimitedWIP Society in Hamburg

Vortrag von D. Anderson zur Frage: wann ist Kanban sinnvoll, wann nicht: http://vimeo.com/30637740

Related Posts:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *