Die häufigsten Fehler bei einer Kanban-Einführung (II)

Bild: Wikimedia Commons / Anick Marie - CC BY-SA 2.0

Dass es bei der Einführung von Kanban gibt es so einiges gibt, auf das man achten muss, dürfte hoffentlich klar sein, sowohl in Bezug darauf woran man auf jeden Fall denken sollte, als auch in Bezug auf das was man besser lassen sollte. In der letzten Kategorie findet sich aber auch etwas das viele überraschend finden - man sollte am Anfang besser keine Work in Progress-Limits (WIP-Limits) einführen. Wenn überhaupt ist das ein späterer Schritt, zu Beginn macht er fast nie Sinn.

Auf den Einen oder Anderen mag das verwirrend wirken. Sind WIP-Limits nicht ein zentraler Teil von Kanban? Und funktioniert die Einführung von Kanban nicht so, dass man alle Arbeit auf einem Board visualisiert und dann begrenzt wie viel davon gleichzeitig durchgeführt wird, damit das was begonnen wird dadurch schneller fertig werden kann? Die Antwort: ja und nein. Ja WIP-Limits sind zentral, und nein, man sollte sie nicht so früh einführen, selbst wenn das gut gemeint ist.

Am einfachsten zu verstehen ist das in dem Fall, in dem alle bisherigen Arbeitspakete einfach auf ein To Do-In Progress-Done-Board gepackt werden. Dann wird sich dort gleichzeitig Arbeit aus verschiedenen Be- oder Verarbeitungsphasen befinden, mit einem gemeinsames WIP-Limit für alle. Dieses würde aber einzelne Gruppen wie z.B. die UX-Designer in die Untätigkeit zwingen, wenn andere, etwa die Tester, so viel parallele Arbeiten durchführen, dass dadurch die Obergrenze erreicht ist.

Aber auch bei ausdifferenzierteren Systemen, wie z. B. Design-Umsetzung-Test-Rollout können frühe WIP-Limits kontraproduktiv sein. Es kann zwar nicht mehr der zuletzt genannte Fall vorkommen, in dem sich verschiedene Phasen gegenseitig blockieren, in einem System das seine Umstellung auf Kanban gerade erst begonnen hat wird es aber noch Abhängigkeiten nach aussen geben, z.B. zu einer Einheit die Testdaten so langsam bereitstellt, dass ein WIP-Limit auch hier Leerlauf erzwingen würde.

Man kann sich noch weitere vergleichbare Konstellationen vorstellen, die zentrale Erkenntnis ist aber klar: wenn eine Organisationseinheit ihre Rahmenbedingungen nicht selbst unter Kontrolle hat erzwingen Work in Progress-Limits im Zweifel nicht mehr Focus und schnelle Fertigstellung sondern führen zu erzwungener Untätigkeit und zu Konflikten mit anderen Einheiten, auf deren Zulieferung oder Beteiligung man angewiesen ist um die selbstgesetzte (den anderen ggf. gar nicht bekannte) Obergrenze zu halten.

Die bessere Reihenfolge im Rahmen einer Umstellung auf Kanban wäre daher, zuerst die Arbeit zu visualisieren (was schon schwieriger ist als man denken sollte), dann den Beteiligten das Wissen und die Berechtigungen geben um ihre Rahmenbedingungen zu verändern und dann erst über WIP-Limits nachzudenken. Es kann (und sollte) dann natürlich auch zu ihnen kommen, der Punkt an dem das passiert liegt dann aber nicht mehr am Anfang sondern deutlich später.

Um zuletzt ein häufiges Gegenargument gleich abzufangen: ja, man könnte es für eine Übergangszeit zulassen, dass die WIP-Limits regelmässig verletzt werden und währenddessen daran arbeiten, dass das irgendwann nicht mehr nötig ist. Das hätte aber eine (unbewusste) Erziehung zur Normverletzung zur Folge, und das ist etwas wovon man jeder Organisation nur dringend abraten kann, wenn sie nicht in ganz andere Probleme geraten will.