“Es ist unmöglich, zweimal in denselben Fluss zu springen. Auch wenn wir in dieselben Flüsse steigen, fließt immer anderes Wasser herbei.”
Heraklit
Viele Konzepte sind so einfach, dass man kaum Ideen findet um einen neuen Blickwinkel aufzuzeigen. Leider gibt es aber auch kein Konzept, das zu einfach für eine fehlerhafte Nutzung wäre.
Kanban ist eine beliebte Methode in der IT, weil ihre Einführung trivial ist und ein Nutzen schnell erkennbar wird. Zum Start wird ein Whiteboard benötigt auf dem die üblichen Arbeitsschritte als Spalten eingetragen werden. Dann schreiben alle Kärtchen der aktuellen und geplanten Arbeiten und dann hängt man sie in die entsprechenden Spalten. Ist man mit einem Arbeitsschritt durch, dann wird das Kärtchen in die nächste Spalte verschoben. Ist das Kärtchen ganz rechts angekommen, dann ist die Arbeit abgeschlossen. Arbeiten, die noch ganz links stehen wurden also noch nicht begonnen.
Wenn die Adaptation an dieser Stelle stockt, dann wurde die Fertigungsstraße erfolgreich eingeführt, aber kein Kanban. Für eine erfolgreiche Einführung von Kanban müssen die vier Grundprinzipien
- Start with what you do now
- Agree to pursue incremental, evolutionary change
- Respect the current process, roles, responsibilities & titles
- Encourage acts of leadership at all levels in your organization
und die sechs Kernpraktiken
- Visualize (the work, workflow and business risks)
- Limit WIP
- Manage Flow
- Make Process Explicit
- Implement Feedback Loops
- Improve Collaboratively, Evolve Experimentally (using models & the scientific method)
gelebt werden.
Die gute Nachricht ist, zwei Prinzipien und eine Kernpraktik wurden erfolgreich übernommen. Da keine Prozesse initial geändert wurden und die bestehende Organisationsstruktur beibehalten wurde sind die Prinzipien 1 und 3 erfüllt. Das Visualisieren der Arbeiten am Board erfüllt die erste Kernpraktik.
Die schlechte Nachricht, die beiden anderen Prinzipien und die restlichen Kernpraktiken sind der schwierige Teil der Kanban Einführung. Nach dem Start im bisherigen Umfeld soll nun die Arbeit und die Organisation durch kleine Schritte effizienter gestaltet werden. Dabei wird nicht nur auf die Änderungen gesetzt, die vom Management benannt werden, sondern es wird auf aktive Mitarbeit aller Ebenen gesetzt. Wie bei der Einführung anderer agilen Praktiken sind auch hier Widerstände, insbesondere durch Besitzstandswahrung und Zukunftsangst, zu bedenken und abzubauen.
Egal wie gut oder schlecht die Prinzipien übernommen wurden, bei der Verwendung der Kernpraktiken zeigt sich häufig, dass die Grundidee, die Durchflusszeit zu reduzieren, nicht verstanden wurde.
“Kanban ist eine Methode in der Softwareentwicklung, bei der die Anzahl paralleler Arbeiten, der Work in Progress (WiP), begrenzt und somit kürzere Durchlaufzeiten erreicht und Probleme – insbesondere Engpässe – schnell sichtbar gemacht werden sollen.”
Wikipedia
Grundsätzlich sollen bei Kanban Arbeiten schnell durch den Prozess geleitet werden, weil nur fertiggestellte Arbeiten einen Wert besitzen. Da jede Arbeit mehrere Arbeitsstationen durchläuft, müssen Staus, Leerläufe, Lagerhaltung, also Muda vermieden werden. Ein probates Mittel dagegen ist das Pull Prinzip, bei dem jede Station sich Arbeit von der vorhergehenden Station nimmt. Eine Station kann also nur dann eine Arbeit übernehmen, wenn die vorhergehende Station ein Ergebnis geliefert hat. Eine Station kann aber bei genügend Arbeit nicht unbegrenzt produzieren, weil sich dann gegebenenfalls Staus vor nachfolgenden Stationen ergeben. Die Staus werden durch eine begrenze Lagerkapazitäten den einzelnen Stationen vermieden. Ist die Kapazität erschöpft, dann stellt die Station ihre Arbeit ein. Der Prozess reguliert sich also selbst.
Bei Kanban wird, mit der Kernpraktik 2, die Work in Progress (WIP) der einzelnen Stationen limitiert. Für ein Entwicklungsteam kann beispielsweise die Anzahl der zu testenden Features begrenzt werden. Damit können Features nicht auf Halde implementiert und in die Spalte Test verschoben werden. Sobald die Spalte Test gefüllt ist, muss eines der Features dort getestet werden. Wurde es erfolgreich getestet, dann wird es in die nachfolgende Spalte geschoben und in der Spalte Test ist wieder Platz für ein weiteres zu testendes Feature.
Häufig wird nicht verstanden, warum das Produzieren auf Halde in der Software Entwicklung vermieden werden muss. Werden mehrere neue Feature erstellt, nicht getestet oder genutzt, dann hat der Auftraggeber keinen Mehrwert. Zusätzlich wird aber auch die Entwicklung gehemmt, weil die verschiedenen Features noch nicht zusammengeführt werden können und damit die Codebasis immer weiter auseinanderläuft. Einzelne Features sind nicht autark, sondern ihre Umsetzung verändert gemeinsam genutzte Codebereiche. Obwohl also jedes Feature für sich vollständig erscheint, kann die Zusammenführung teuer werden. Und diese Kosten steigen mit der Dauer.
Ein anderes Punkt der immer sehr leicht vergessen wird. Niemand erinnert sich nach einigen Wochen noch an die Details einer Implementierung,
“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”
Eagleson’s law
Daher sollten Implementierung, Code-Reviews, Tests, Dokumentation und Auslieferung immer zeitnah erfolgen.
Wie hoch der Limit an einer einzelnen Station gesetzt werden kann, hängt von der Größe des Teams und der Art der Station ab. Die ungefähre Größe kann auch anhand der Effizienz des Prozesses und der Teamgröße berechnet werden, soll aber hier nicht näher beleuchtet werden. Wichtig ist nur zu wissen, dass der Wert in einem gesunden Bereich, nicht zu hoch aber auch nicht zu niedrig liegen darf. Liegt er zu hoch, dann wird auf Halde produziert und liegt er zu niedrig, dann stauen sich die Arbeiten.
Damit Kanban zum Erfolg wird, sind Kontrolle des Durchflusses und Kaizen, die stetige Verbesserung notwendig. Die Kontrolle stellt sicher, dass der Durchfluss nicht ins Stocken gerät und die Arbeiten effizient durch den Prozess gelangen und die stetige Verbesserung sorgt dafür, dass der Prozess mit seinen Arbeitsstationen optimiert wird.
Denn auch das wusste schon Heraklit.
“Die einzige Konstante im Universum ist die Veränderung.”
Heraklit