Work in Progress Limits

WIP-Limits sind Beschränkungen, wie viele Elemente sich gleichzeitig in einer bestimmten Phase – oder im gesamten System – in Bearbeitung befinden können.

Das klingt falsch. Sollten wir nicht an so viel wie möglich arbeiten? Ist mehr Aktivität nicht besser?

Nein. Und hier ist der Grund:

Little's Law: Durchlaufzeit = WIP / Durchsatz

Wenn der Durchsatz konstant ist, halbiert eine Halbierung des WIP die Durchlaufzeit. Das ist Mathematik, keine Meinung.

Kontextwechsel: Jedes zusätzliche Element in Bearbeitung fragmentiert die Aufmerksamkeit. Bei 1 Element haben Sie 100 % Fokus. Bei 5 Elementen haben Sie 20 % Fokus auf jedes. Der Kontextwechsel zwischen ihnen verbrennt den Rest.

Warteschlangenbildung: Hoher WIP bedeutet, dass Elemente in Warteschlangen warten. Niedriger WIP bedeutet, dass Elemente schneller durchlaufen.

Fertigstellen vor Beginnen: Mit WIP-Limits müssen Sie etwas fertigstellen, bevor Sie etwas Neues beginnen. Das erzwingt Abschluss.

Das kontraintuitive Ergebnis: weniger gleichzeitig zu tun bedeutet insgesamt mehr fertigzustellen.

Woher wissen Sie, welches WIP-Limit Sie setzen sollen?

Beginnen Sie mit Beobachtung: Zählen Sie, wie viele Elemente gerade in Bearbeitung sind. Wenn Sie 20 Elemente auf 5 Personen verteilt haben, ist das Ihre Baseline.

Halbieren Sie es: Ernsthaft. Die meisten Teams haben viel zu viel WIP. Es zu halbieren ist normalerweise ein guter Ausgangspunkt.

Pro Phase vs. systemweit: Sie können Limits pro Phase setzen (z. B. max. 3 Elemente im Code Review) oder systemweit (z. B. max. 10 Elemente über alle Phasen). Beginnen Sie mit dem, was für Ihr Team einfacher ist.

Eins pro Person plus Puffer: Ein gängiger Ausgangspunkt ist n+2, wobei n die Teamgröße ist. Ein Team von 4 könnte also mit einem WIP-Limit von 6 beginnen.

Anpassen basierend auf Ergebnissen: WIP-Limits sollten eng genug sein, um Flow zu erzeugen, aber nicht so eng, dass Leute nichts zu tun haben. Wenn das Limit nie erreicht wird, ist es zu hoch. Wenn Leute ständig untätig sind, könnte es zu niedrig sein.

Das Ziel ist nicht, das „perfekte" WIP-Limit zu finden – es geht darum, eine Zwangsfunktion zu schaffen, die Abschluss vorantreibt und Probleme sichtbar macht.

WIP-Limits funktionieren nur, wenn Sie reagieren, wenn Sie sie erreichen. Was tun Sie, wenn das Limit erreicht ist?

Schwärmen: Hören Sie auf, was Sie tun, und helfen Sie, den Engpass zu beseitigen. Wenn Code Review an seinem Limit ist, helfen Entwickler beim Review, anstatt neuen Code zu schreiben.

Produktiv warten: Wenn Sie keine neue Feature-Arbeit beginnen können, machen Sie Verbesserungsarbeit: zahlen Sie technische Schulden ab, schreiben Sie Tests, automatisieren Sie einen schmerzhaften Prozess.

Blockaden eskalieren: Wenn das Limit erreicht wird, weil etwas blockiert ist, eskalieren Sie sofort. Die Blockade kann sich nicht verstecken.

Analysieren: Warum wird das Limit erreicht? Ist diese Phase der Engpass? Gibt es ein systemisches Problem?

Was Sie NICHT tun sollten:

• Das Limit ignorieren („nur dieses eine Mal")
• Das Limit erhöhen, um dem Gespräch auszuweichen
• Arbeit „außerhalb des Boards" beginnen
• Elemente anders zählen, um die Zahl zu manipulieren

Das Limit ist da, um Druck zu erzeugen. Druck macht Probleme sichtbar. Probleme, wenn sie angegangen werden, führen zu Verbesserung.