Start » Alle Inhalte » Blog » Work in Progress (WIP) Limits einfach erklärt

Work in Progress (WIP) Limits einfach erklärt

Priorisierung ist ein wesentliches Merkmal agiler Arbeitsweisen und das WIP Limit die dazugehörige Praktik. Denn WIP steht für “Work in Progress”, bezeichnet also die aktuell in Umsetzung befindlichen Arbeiten. Entsprechend ist das WIP Limit die Limitierung der laufenden Arbeiten. Das WIP Limit hat seinen Ursprung in der Kanban Methode

In diesem Beitrag erkläre ich Dir an einem einfachen Beispiel die Kraft von WIP Limits und warum es sinnvoll ist, mit WIP Limits zu arbeiten.

Vorteile WIP Limits

Mit Work in Progress Limits zu arbeiten hat mehrere Vorteile. 

  1. Task Switching: Du vermeidest die unsichtbaren Kosten, die entstehen, wenn Du von einer unvollendeten Aufgabe zur nächsten springst. Multitasking ist ein Mythos, erst recht für moderne Wissensarbeit.
  2. Wartezeiten: Unvollendete Aufgaben verstopfen und stören den Arbeitsfluss. Dadurch entstehen Wartezeiten, eine zentrale Verschwendung im Lean Verständnis.
  3. Überlastung: WIP Limits schützen dein Team und deine Organisation vor Überlastung. Die Überlastung des Systems ist im Lean Verständnis eine weitere Form der Verschwendung.
  4. Engpässe: In einem Kanban Board werden mit WIP Limits Engpässe besser sichtbar und transparent. Wenn Du zu viele Aufgaben “in progress” hast, dann geht der Blick dafür verloren, welcher Arbeitsschritt und welche dazugehörige Kompetenz ein Engpass ist.

WIP Limits Beispiel

Zur Veranschaulichung von Work in Progress Limits stell Dir das folgende Beispiel vor. Dein Team hat fünf offene Arbeitsaufträge von fünf verschiedenen Kunden. Für jeden Arbeitsauftrag benötigst Du fünf volle Werktage. Nun berechne bitte die Wartezeit aller Kunden, wenn Du …

  1. alle Arbeitsaufträge gemeinsam startest.
  2. einen Arbeitsauftrag nach dem anderen bearbeitest..

Szenario A – Alles auf einmal

Wenn Du alle Arbeitsaufträge gemeinsam startest, kannst Du in jeder Woche einen Tag pro Auftrag investieren. D.h. erst in der fünften Woche kannst Du beginnen, Aufträge zu liefern. So erhält Kunde 1 seine Lieferung nach 21 Tagen Wartezeit, Kunde 2 nach 22 Tagen uswusf. In Summe hast Du durch das parallele Vorgehen mit fehlendem WIP Limit eine Wartezeit von 115 Tagen kreiert. Allerdings musst Du keine Entscheidung treffen und einen Kunden bevorzugen. Du behandelst alle gleich, kreierst damit mehr Wartezeiten und Verschwendung als eigentlich nötig wäre. Wenn Du zudem noch für deine Aufträge im Moment der Lieferung bezahlt wirst, dann erzielst Du deinen geballten Cash Flow erst in Woche 5. 

Wartezeiten Szenario AKunde 1Kunde 2Kunde 3Kunde 4Kunde 5
Woche 1
Woche 255555
Woche 355555
Woche 455555
Woche 5235
Summe: 11521 22 23 24 25

Szenario B – Ein Kloß nach dem anderen

Wenn Du dagegen ein WIP Limit von eins einführst, dann hast Du den ersten Kunden nach 5 Tagen schon bedient, den zweiten nach 10 Tagen uswusf. In Summe hast Du durch das serielle Vorgehen und das konsequente Abarbeiten mit strengem Work in Progress Limit von einem nach dem anderen Auftrag eine gesamte Wartezeit von 75 Tagen. Das einzig Schwierige an diesem Vorgehen ist, dass Du eine Entscheidung treffen darfst, mit welchem Kunden Du beginnst und welchen Du vermeintlich bevorzugst. Dafür generierst Du anders als in Szenario A einen regelmäßigen Cash Flow.

Wartezeiten Szenario BKunde 1Kunde 2Kunde 3Kunde 4Kunde 5
Woche 1
Woche 205555
Woche 300555
Woche 400055
Woche 500005
Summe: 75510152025

WIP Limits weiter gedacht

In seinem Buch “Agilität neu denken” beschreibt Klaus Leopold eine elegante Erweiterung des WIP Limits. Demnach lohnt sich nicht nur die Betrachtung des “Work in Progress”, sondern vor allem des “Work in Process”. Also alle Arbeiten, die im aktiven Arbeitsprozess sind, aber aktuell nicht weiter bearbeitet werden können, weil das eine auf das andere Team wartet, also Abhängigkeiten bestehen. Durch diese gesamthafte Betrachtung und die Ausweitung des WIP Limits auch auf Arbeiten im “Work in Process” gewinnt eine Organisation einen ganzheitlichen Blick auf Wartezeiten und damit eine der zentralen agilen Blockaden. Abhängigkeiten und daraus resultierende Wartezeiten kriegst Du übrigens mit dem Flight Level Model in den Griff. 

Fazit – Wenn es nur so einfach wäre

WIP Limits klingen plausibel und sehr einfach, erfordern aber viel Disziplin und Konsequenz. Schließlich musst Du immer wieder priorisieren und aufs Neue entscheiden, welche Arbeiten nun am höchsten priorisiert sind. Das ist anstrengend, erfordert eine gute Auseinandersetzung und kann sich wie in den beiden Szenarien oben auch schon mal “unfair” anfühlen. Einfach weil Du ein Vorhaben oder einen Auftrag dem anderen vorziehst. D.h. irgendjemand, ob ein Kunde oder ein Kollege, darf sich nun hinten anstellen und warten. Jedoch siehst Du an beiden Beispielen, dass Du es Dir nicht so einfach machen darfst, dass “irgendwie alles wichtig ist”. Denn wie sagte schon Jim Collins einmal “ If you have more than three priorities, you don’t have any.” Jetzt darfst Du dein eigenes ideales WIP Limit herausfinden.. 

Viel Spaß dabei.

Signatur

Neue #DNO Blogs direkt in deiner Inbox

No SPAM, promised

3 Kommentare

Thomas Hucke
16.09.2022

Sehr gute Erklärung zu WIP Limits. Die Beispiele sind spitze!
Vielen Dank dafür!

Nils
21.09.2022

Wie immer eine sehr gute Erläuterung – vielen Dank!

Ich vermute, dass in Szenario A die Dauer sich noch signifikant erhöht, da nicht konzentriert an einem Auftrag gearbeitet wird. Durch die laufenden Wechsel zwischen den Aufträgen müssen sich alle immer erst wieder in den Auftrag und die aktuelle Themenstellung einarbeiten.

Basierend auf der Theorie von Gerald Weinberg wirkt sich selbst das Hinzufügen eines einzelnen Projekts zur aktuellen Arbeitslast äußerst schwächend. Man verliert mindestens 20% seiner Zeit und das steigt deutlich mit jedem weiteren Projekt.

Andreas Diehl
22.09.2022

Danke Nils.

Genau, das skizzierte Szenario ist schon der „best case“, weil die Kosten des Task Switching eben nur schwer zu quantifizieren sind.

Hast Du noch eine genauere Referenz zu den 20% von Gerald Weinberg?

Neuer Kommentar
Schreibe einen Kommentar