Kanban, wer hat’s erfunden?
Nein, das waren nicht die Schweizer. Erfunden, respektive entwickelt wurde Kanban von Taiichi Ohno in der japanischen Toyota Motor Corporation. Der Grund hierfür war die ungenügende Produktivität des Unternehmens im Vergleich zu amerikanischen Konkurrenten.
Kanban ist eine Methode der Produktionsprozesssteuerung und richtig angewendet lassen sich damit Engpässe im Produktionsablauf sichtbar machen. Es lässt sich damit also Transparenz schaffen, wie sie vor allem auch von Scrum gefordert wird.
Scrum und Kanban gleichzeitig?
Aber klar doch; ein eindeutiges JAIN! Scrum ist Scrum und Kanban ist Kanban. Das Sprint Board gehört, wie der Name erahnen lässt, zu Scrum. Als Kanban Board aufgebaut, lassen sich damit Engpässe ausfindig machen und beheben.
Nun aber zum Thema:
Kanban falsch verstanden
Die zwei gängigsten Fehler sind:
- der eigentliche Produktionsprozess – die Umsetzung des Sprint Plans – wird nur über eine einzige Spalte (oftmals mit “In Development” oder “WiP” (Work in Progress) betitelt) abgebildet und / oder
- es fehlen die Wartepositionen (Ready-4-…), aus denen heraus der nachfolgende Produktionsschritt seine Arbeiten ziehen kann. Kanban arbeitet nach dem Pull-Prinzip.
Faaalsch …
Wie möchte man mit nur einer einzigen Spalte, die den gesamten Produktionsprozess abbildet feststellen, ob der Prozess irgendwo ein Bottleneck beinhaltet, wenn er nicht in seine einzelnen Schritte aufgegliedert ist?
Wie möchte man beispielsweise feststellen, ob die Kollegen mit dem Testing hinterherkommen, wenn die Softwareentwickler einfach alle fertig umgesetzten User Stories sogleich in die Spalte Testing verschieben.
Kanban richtig eingesetzt / angewandt
- der Produktionsprozess – die Umsetzung des Sprint Plans – wurde in die drei Arbeitsschritte In Dev., Code Review und Testing aufgeteilt.
- nachdem in Kanban das Pull-Prinzip gilt (pull = ziehen), wurde vor den jeweiligen Arbeitsschritten jeweils eine Warteposition (Ready-4-…) eingeführt.
Interpretation des Geschehens
Annahme:
Der Sprint, den das vorliegende Sprint Board abbildet, dauert 3 Wochen und wir befinden uns in der Mitte der letzten Woche.
- In der Spalte Ready-4-Testing tummeln sich ziemlich viele User Stories, die noch getestet werden müssen. Es scheint so, als würde das Testing nicht hinterherkommen. Bottleneck!
- Wir sind fast am Ende vom Sprint angelangt und in der Spalte To Do sind noch ziemlich viele User Stories, deren Umsetzung noch nicht einmal angefangen hat. Ob das Sprint-Ziel erreicht wird? Wohl eher nicht.
Wenn sich User Stories, und / oder (Sub-) Tasks, in einer Warteposition häufen, scheint es in diesem Prozess irgendwo nicht voran zu gehen. Hier besteht ein Bottleneck / ein Engpass. Die Gründe dafür können manchmal vielfältig sein und das muss natürlich untersucht werden. Wichtig ist aber, dass ein gutes Kanban Board so einen Engpass aufdeckt.
Würden sich die User Stories in der Spalte Ready-4-Approval häufen, dann wäre der Product Owner, der für die Abnahme zuständig ist, das Bottleneck.
Conclusio
Nicht selten zeigt das Velocity Chart (siehe Jira), dass ein Team in Regelmäßigkeit sein Sprint-Ziel verfehlt. In solch einem Fall bedarf es der eingehenden Analyse der Gründe dafür. Wenn aber nicht ausreichend Transparenz über das Geschehen innerhalb des Sprints gegeben ist, wird man auch keinen Hebel für Optimierung finden können. Das Sprint-Geschehen darf keine Blackbox sein.
