Mehr erledigen mit dem WIP-Limit in Kanban

Das WIP-Limit in Kanban dient dazu, die zweite Kanban-Praktik „Begrenze die Menge paralleler Arbeit“ umzusetzen. Ohne ein WIP-Limit wird Dein Team keinerlei Nutzen aus Kanban ziehen.

In diesem Grundlagenartikel zeige ich Dir, warum es sinnvoll ist, parallele Arbeit zu begrenzen bzw. was passiert, wenn Du es nicht tust. Außerdem stelle ich Dir anhand einiger Beispiele die grundsätzlichen Optionen vor, die Ihr mit Eurem Kanban Team habt, wenn Ihr ein WIP-Limit einführen möchtet.

Die Einführung eines WIP-Limits, um dadurch parallele Arbeit zu begrenzen, erscheint auf den ersten Blick kontraproduktiv. Wie soll es denn gelingen, mehr fertigzustellen, wenn man weniger arbeitet?!

Ein WIP-Limit bedeutet jedoch nicht, dass Dein Team insgesamt weniger arbeitet, sondern dass es an weniger Dingen gleichzeitig arbeitet.

Mit Hilfe des WIP-Limits erzeugt Kanban dabei gleich mehrere Vorteile. Erstens sorgen es dafür, dass Dein Team nicht mit Aufgaben überfrachtet wird und an zu vielen Dingen gleichzeitig arbeitet. Zweitens hilft es dabei, Engpässe in Eurem Workflow aufzudecken. Drittens senkt es sogenannte Wechselkosten, die durch Multitasking entstehen. Und viertens etabliert das Work In Progress Limit ein Pull-System

Je mehr Dinge zu erledigen sind, desto mehr Arbeit wird in der Regel begonnen. (Weil ja soooo viel zu tun ist.)

Dadurch überlastet Ihr jedoch Eure Kapazitäten und im Ergebnis beginnt Ihr zwar sehr viel (und alle sind beschäftigt), stellt jedoch nichts fertig.

Wenn Arbeit unkontrolliert in Euren Workflow schwappt, dann verstopft Ihr zwangsläufig Euer System und die zu erledigenden Aufgaben türmen sich zu immer höheren Bergen auf.

Das Kanban WIP-Limit begrenzt parallele Arbeit und sorgt dafür, dass Euer Workflow nicht verstopft.

Wenn viele Dinge gleichzeitig bearbeitet werden, dann könnt Ihr in Eurem Team kaum feststellen, wie gut Euer aktueller Workflow funktioniert. Das ist ungefähr so, als wolltet Ihr in einem großen Gewässer mit bloßem Auge feststellen, welche Strömungen es darin gibt.

Reduziert Ihr jedoch die Menge an paralleler Arbeit auf ein notwendiges Minimum, dann könnt Ihr auf Euerm Kanban Board in der Regel schnell erkennen, wo sich Engpässe verbergen, die dafür sorgen, dass sich Euer Workflow verlangsamt.

Ein weiterer Vorteil von WIP-Limits ist die Vermeidung sogenannter Wechselkosten (Switching Costs). Denn wenn Ihr Multitasking betreibt und zwischen mehreren Aufgaben oder Projekten hin- und herwechselt, entstehen automatisch „Reibungsverluste“.

Ihr müsst dann immer wieder Zeit aufwenden, um Euch gedanklich in eine bereits begonnene Aufgabe wieder einzudenken, bevor Ihr produktiv daran weiterarbeiten könnt.

WIP-Limits senken diese unnötigen Aufwände, weil Ihr im besten Fall neue Aufgaben erst dann beginnt, wenn Ihr die vorherige abgeschlossen haben.

Ein Work In Progress Limit sorgt dafür, dass zu erledigende Arbeit nicht „einfach ins System gedrückt“ wird, sondern nur dann weiter voranschreitet, wenn an der entsprechenden Station Eures Workflows auch genügend Kapazitäten frei sind, das Work Item auch direkt zu erledigen. In Kanban sprechen wir deshalb auch von einem Pull-System.

Visuell lässt sich Little’s Law mit Hilfe eines Dreiecks auf dem Cumulative Flow Diagram (CFD) erklären. Dabei steht jede Seite dieses Dreiecks für eine der drei Metriken Work In Progress, Cycle Time und Throughput dieser Formel.

Wie Du sehen kannst, wird die horizontale Linie dieses Dreiecks (die für die durchschnittliche Cycle Time steht) automatisch kürzer, wenn die vertikale Linie (Work In Progress) verringert wird. Je „schmaler“ also die Schicht des Work In Progress‘ auf dem CFD wird, desto geringer fällt auch die durchschnittliche Cycle Time aus.

Das WIP-Limit in Kanban dient genau diesem Zweck: Es sorgt dafür, dass so wenig Work Items wie möglich aktiv bearbeitet werden, wodurch die gelben bis roten Bereiche auf dem CFD so schmal wie möglich bleiben. Gleichzeitig sorgt das dafür, dass die Cycle Time (im Durchschnitt) so kurz wie möglich wird.

Die am häufigsten anzutreffende Umsetzung des WIP-Limits ist die Begrenzung von paralleler Arbeit pro Arbeitsschritt. Dabei entscheidet Ihr Euch für die Begrenzung paralleler Arbeit pro Spalte bzw. Status einer zu erledigenden Aufgabe.

Hat eine Spalte ihr Limit erreicht, solltet Ihr Euch darauf fokussieren, die dort befindlichen Work Items fertigzustellen, sodass sie in die nächste Spalte weiterwandern können. (Unter Umständen kann es natürlich auch sein, dass Work Items nicht weitergezogen werden können, weil die nachfolgende Spalte der eigentliche Engpass Eures Workflows ist.)

Manche Kanban Teams bevorzugen auch ein WIP-Limit, das ihnen ein wenig mehr Flexibilität bietet und lediglich die Anzahl aktiver Aufgaben begrenzt. (Die Anzahl an Work Items pro Arbeitsschritt, Spalte bzw. Zustand ist in diesem Fall irrelevant.)

Das Sprint Backlog in Scrum funktioniert übrigens ähnlich:

Es begrenzt die Arbeit eines Scrum Teams auf das, was im Sprint Planning festgehalten wurde. So wird verhindert, dass während eines Sprints neue oder zusätzliche Arbeit hinzukommt.

Manche Teams nutzen auch Swimlanes in ihrem Kanban Board, beispielsweise für unterschiedliche Work Item Types.

Hier siehst Du ein Beispiel für das WIP-Limit eines Kanban Teams, das kritische bzw. dringende Aufgaben (blaue Tickets) auf maximal 1 Ticket begrenzt.

Auf diese Weise ist es diesem Team möglich, dringende Aufgaben kontrolliert in seinen Workflow einzubringen. (Statt sich davon überschwemmen zu lassen.)