Little’s Law – wie man WIP-Limits möglichst nicht erklärt und wie es vielleicht besser geht

Kaum eine Kan­ban-Ein­füh­rung ver­geht, ohne dass irgend­wann Litt­les Gesetz erwähnt und als (meist die) Erklä­rung für die Sinn­haf­tig­keit von WIP-Limits her­an­ge­zo­gen wird. Theo­re­tisch mag die­ser Ansatz rich­tig sein, prak­tisch erscheint er mir sehr wenig zielführend.

Die wenigs­ten Infor­ma­ti­ker (und noch weni­ger Betriebs­wirt­schaft­ler) wer­den das The­ma „War­te­schlan­gen­theo­rie“ im Stu­di­um genos­sen haben – und mit einer hüb­schen For­mel am Flip­chart lässt sich auch nur beein­dru­cken, wenn sich der Trai­ner beim Erklä­ren der betei­lig­ten Varia­blen und Rah­men­be­din­gun­gen nicht hoff­nungs­los ver­has­pelt. Klar wird oft nur: Auch das Stu­di­um des Trai­ners ist schon lan­ge her – und die tol­le For­mel viel­leicht doch gar nicht so einleuchtend.

Genau genom­men scheint mir das Gegen­teil der Fall zu sein: Litt­les Theorem​¹ ist für die meis­ten Men­schen hoch­gra­dig kon­train­tui­tiv; die oft nicht ganz sat­tel­fes­ten Erklä­rungs­ver­su­che enden erstaun­lich häu­fig sogar in der m. E. sehr schäd­li­chen Erwar­tungs­hal­tung, eine gerin­ge­re Durch­lauf­zeit bedeu­te zwin­gend einen höhe­ren Durch­satz. Dabei hal­te ich eine funk­tio­nie­ren­de Erklä­rung für wirk­lich wich­tig, ver­stößt die Ein­füh­rung von WIP-Limits doch gegen die Instink­te vie­ler Men­schen (m. E. vor allem gegen die Instink­te der meis­ten Führungskräfte).

Den­noch: Viel zu häu­fig dürf­te die Erklä­rung mit Little’s Law begin­nen – und dann auch gleich enden, so, als wäre damit per se bereits etwas Wich­ti­ges gesagt, tie­fe Ein­sicht erzeugt. Nichts davon ist m. E. der Fall – und wich­ti­ge Vor­tei­le von WIP-Limits wer­den zudem durch die zwar natür­lich nicht unrich­ti­ge, aber in mei­nen Augen unvoll­stän­di­ge und vor allem nur all­zu häu­fig unver­stan­de­ne Erklä­rung unterschlagen.

Wie es vielleicht besser geht: Hilfreiche Metaphern statt Formeln

Ich erklä­re die Wir­kung von WIP-Limits am liebs­ten mit einem Fluss – nicht etwa mit dem Arbeits­fluss, son­dern tat­säch­lich mit einem phy­si­schen Fluss in der Land­schaft (vgl. hier): An den Strom­schnel­len fließt das Was­ser schnel­ler; aber mehr, als durch den Eng­pass passt, passt eben auch nicht hin­durch – es sei denn, ich erwei­te­re den Fluss an genau die­ser Stelle​². Gera­de an der Eng­stel­le fließt es zudem sehr gleich­mä­ßig, die Wir­bel sind davor und vor allem dahin­ter. Über­tra­gen auf den Arbeits­fluss: Die Durch­lauf­zeit und ihre Varianz​³ sinkt, aber der Durch­satz steigt nur, wenn ich auch mehr Men­schen dar­an arbei­ten lasse.

Ori­en­tiert sich das WIP-Limit an der tat­säch­li­chen Kapa­zi­tät, ist es also gar kein „künst­li­cher Eng­pass“ (als das WIP-Limits oft ange­se­hen wer­den), son­dern nur eine Expli­zie­rung des Faktischen​⁴ – und es gilt vor allem, den vor­han­de­nen Eng­pass opti­mal auszulasten​⁵. Wird das Fak­ti­sche des Eng­pas­ses mit der Meta­pher des Flus­ses nicht deut­lich genug, hilft mir ergän­zend oft die Meta­pher vom Flughafen​⁶: Es soll­ten im Mit­tel eben­so vie­le Flug­zeu­ge abflie­gen wie lan­den – eben­so viel Arbei­ten fer­tig wer­den wie neue Arbeit in das Sys­tem gespeist wird –, andern­falls sta­peln sich die Flug­zeu­ge auf dem Rollfeld:

Wich­tig neben die­sen Erklä­run­gen erscheint mir aber vor allem, die wei­te­ren Vor­tei­le von WIP-Limits nicht zu unter­schla­gen (wie es mit der For­mel am Flip­chart – der Reduk­ti­on auf das The­ma „War­te­schlan­ge“ – schnell passiert):

• Mehr WIP bedeu­tet mehr Kon­text­wech­sel und damit mehr Over­head. Hier hilft mir in der IT oft das Bild der CPU. Jeder, der sich ein wenig mit hard­ware­na­her Pro­gram­mie­rung beschäf­tigt hat, wird bestä­ti­gen kön­nen: Con­text Swit­ches erzeu­gen einen hohen Over­head, der gesam­te Zustand der CPU muss gesi­chert wer­den, bevor sich die CPU (ja nur zeit­wei­lig) ande­rer Arbeit wid­men kann – und das Ver­hält­nis von Threads zu CPU-Ker­nen will wohl aus­ba­lan­ciert sein. Erstaun­li­cher­wei­se kommt kaum jemand auf die Idee, dass das mit Men­schen kaum anders ist: men­ta­le, sozia­le oder fak­ti­sche Rüst­zei­ten sind ein enor­mer Effi­zi­enz­kil­ler und ver­ur­sa­chen zudem schlicht­weg Stress​⁷.

• Die Feh­ler­ra­te steigt mit der Anzahl der gleich­zei­ti­gen Auf­ga­ben, Mul­ti­tas­king ver­ur­sacht Feh­ler und Stress​⁸. Die­ser Sach­ver­halt ist woh­lerforscht; ich nei­ge prak­tisch aber dazu, an die­ser Stel­le ein­fach nur auf das The­ma „Smart­phone am Steu­er“ als Bei­spiel zu verweisen​⁹.

• Limi­tiert man expli­zit die Men­ge der Arbeit im (sowie­so fak­ti­schen) Eng­pass, wer­den struk­tu­rel­le oder sich wie­der­ho­len­de Pro­ble­me im Arbeits­fluss viel offen­sicht­li­cher als im Fal­le eines ein­fach nur „ver­stopf­ten“ Eng­pas­ses – schon allein, weil man weni­ger Arbeits­ein­hei­ten unter­su­chen muss, um die Pro­ble­me zu iden­ti­fi­zie­ren. Liegt in der Strom­schnel­le – um auf den Fluss zurück­zu­kom­men – etwas quer und staut sich das Was­ser, ist dies sofort offen­kun­dig. Staut sich die Arbeit aber ein­fach nur schein­bar ver­teilt im gesam­ten Sys­tem, ver­stellt die­ser Stau meist die Sicht auf die wah­ren Pro­ble­me der Abarbeitung.

• Die Wahr­schein­lich­keit, eine Kul­tur des „Die-Din­ge-auch-fer­tig-Machens“ zu erzeu­gen, steigt deut­lich. In vie­len Orga­ni­sa­tio­nen ist es erstaun­lich üblich, die Din­ge im „95% fertig“-Zustand zu belas­sen – und dann Unfer­ti­ges gleich­zei­tig womög­lich als Beweis für die eige­ne Über­las­tung oder wahl­wei­se der eige­nen Wich­tig­keit demons­tra­tiv vor sich her­zu­tra­gen. WIP-Limits kön­nen das ver­hin­dern, kön­nen sogar dazu füh­ren, dass „fer­tig gewor­den sein“ wie­der gefei­ert wird!

• Oft gehört ist die Behaup­tung, WIP-Limits wür­den gera­de­zu auto­ma­tisch ein Pull-Sys­tem erzeu­gen, sei­en womög­lich gar eine not­wen­di­ge Vor­aus­set­zung dafür. Ich hal­te bei­des für Unsinn: Ers­te­res wäre nur rich­tig, wenn das Limit zum „Pull“ zwin­gen wür­de – es begrenzt ihn aber nur. Wäre letz­te­res rich­tig, gäbe es nicht so vie­le Men­schen, die sich aus eige­nem Antrieb den Schreib­tisch bis zum Anschlag mit Arbeit fül­len – auch das ist irgend­wie ein Pull-Sys­tem, aber eben ohne WIP-Limits und damit oft­mals weit­ge­hend unkon­trol­liert. Was aber (gera­de ange­sichts die­ses Bei­spiels) offen­kun­dig rich­tig ist: WIP-Limits ermög­li­chen – in Ver­bin­dung mit wei­te­ren Pro­zess­re­geln bspw. für den eigent­li­chen „Pull“ –, ein Pull-Sys­tem zu steu­ern, nicht nur i. S. eines oft doch recht kyber­ne­ti­schen „visu­el­len Manage­ments“ am Kan­ban-Board, son­dern ins­be­son­de­re auf­grund der vor­ge­nann­ten Aspek­te eben auch i. S. wert­schät­zen­der (Menschen‑)​Führung.

All das steckt nicht in L = λW – und ist doch so wich­tig und in vie­len Fäl­len sogar viel wirk­sa­mer als die blo­ße Betrach­tung und Modi­fi­ka­ti­on des War­te­sys­tems. Es mit eini­gen weni­gen prä­gnan­ten Meta­phern zu illus­trie­ren, erscheint mir deut­lich wirk­sa­mer als die nack­te Theo­rie – und ergänzt man sei­ne Erläu­te­run­gen auch noch durch prak­ti­sches (und hap­ti­sches) Erle­ben – im Zwei­fel in Form eines Simulations-„Spiels“​¹⁰ –, gewinnt die­se Wirk­sam­keit womög­lich auch an Nachhaltigkeit.

☰