Perspektivenwechsel

Wer Pull sagt, muss auch WiP sagen

Markus Andrezak

Was bedeuten die in Kanban zentralen Begriffe Pull und WiP-Limit?

Paul: „Wir haben Kanban eingeführt!“

Gerd: „Na und, is doch easy! Workflow visualisieren, Work-In-Progress-Limits einführen, Pull macht eh jeder, und schon is alles gut!“

Paul: „Echt? Bei uns war’s schwer! Bis WiP-Limits wirklich beobachtet wurden und Pull Vertrauen fand – da vergingen Monate!“

So kann es gehen – es gibt sehr unterschiedliche Perspektiven auf die Schwierigkeiten einer Kanban-Einführung. Ich persönlich glaube fest daran, dass diejenigen, die diese als „leicht“ empfinden, vor einer konsequenten Einhaltung von WiP-Limits und dem Pull-Prinzip Halt machen und so „Kanban-But“ pflegen, also eine lässliche Pseudoanwendung von Kanban vornehmen.

Was bedeuten die in Kanban zentralen Begriffe Pull und WiP-Limit?

Pull heißt, dass an einem Prozessschritt mit der Arbeit an einem „Werkstück“ – einem Task oder einem Minimal Marketable Feature (MMF) begonnen wird, sobald zwei Bedingungen erfüllt sind: 1) Der Task wurde vom vorherigen Prozessschritt fertiggestellt, und 2) es gibt entsprechende Kapazität im neuen Schritt. In Kanban-Begriffen heißt dies, dass das WiP-Limit auch dann eingehalten wird, wenn mit dem neuen Task begonnen wird. Im Gegensatz zu Push bedeutet Pull, dass die Arbeit nicht vom Vorgänger zugeschoben wird, sondern vom nächsten Schritt aktiv „gezogen“ wird. WiP steht für Work in Progress, also die Menge der gerade bearbeiteten Aufgaben. WiP-Limits werden bei Kanban gesetzt, um das System generell nicht mit unfertiger Arbeit (= Verschwendung) zu verschmutzen, im Speziellen aber auch, um die eine Stelle, die den Engpass („Bottleneck“) im System darstellt, optimal auszulasten, ohne dass ein großer Stau davor entsteht.

Abb. 1: Beim Push-Prinzip wird die Arbeit zugeteilt

Was ist nun das Problem bei der Einführung von Pull im Unternehmen? Nun, Pull einzuführen bedeutet erst einmal, den Angestellten ein riesiges Maß an Vertrauen entgegen zu bringen. Ganz platt gesagt, ist ja erst einmal nicht klar, warum etwa ein Programmierer einen Task „pullen“ sollte anstatt z. B. ins Freibad zu gehen. Doch der Mensch trägt mehr Ehre in sich, als weithin vermutet werden mag. Denn tatsächlich: Die Tasks werden gepullt – immer wieder. Die Realität lässt daran keinen Zweifel. Dennoch stellt für viele Führungskräfte, aber auch fast alle Mitarbeiter, das freie Spiel der Kräfte über Pull eine Herausforderung dar. Zum einen sind Technologieabteilungen umtriebige Umgebungen und Geduld ist dort eine seltene Tugend. Zum anderen sind Führungskräfte oft an „Kontrolle“ und Zuweisungen von Arbeit gewöhnt. Wohin man schaut, stellt – auch in kreativen Bereichen – Push die Regel dar, Pull aber die Ausnahme. Vor allem jedoch ist fast jede Berufsausbildung auf das Predigen von Push und die Kontrolle durch Push ausgelegt. Das klassische Bild des Projektleiters ist vor allem das Bild eines Meisters des Pushs. Dabei werden unter Wahrung von Kontrolltheorien und jeweils kulturell und gesellschaftlich akzeptierten Regelwerken bis hin zu psychologischen Modellen unterschiedlichste Push-Modelle sowie das Balancieren von Push-Abhängigkeitsketten, sogar Multitasking und vor allem Multiprojektmanagement gelehrt und praktiziert. Insbesondere Zeitlinien werden gnadenlos mit Push verwaltet („Kommt Feature X in Release Z?“, „Nein, das kann kaum noch klappen“, „Dann mach, dass es klappt! Zauber doch mal!“). Das aufwändig vom Entwickler eingeholte Commitment und die Schätzung sind vor den brutalen Konsequenzen eines verpassten Releases schnell Makulatur – entgegen jeder Rationalität.

Abb. 2: Beim Pull-Prinzip werden die Aufgaben von den jeweiligen Personen „abgeholt“, sobald Kapazitäten dafür bereitstehen

Na gut, Pull ist schwierig. Aber wo ist das Problem mit den WiP-Limits? Ganz einfach: die meisten Entwickler hassen sie. Dafür gibt es viele valide Gründe. Zum einen erzwingen WiP-Limits Disziplin. Kaum habe ich meinen zweiten, dritten Task wegen eines auftauchenden Problems vertagt, laufe ich auch schon aus meinem Wip-Limits (und das sogar in „verzeihenden“ Kanban-Systemen mit großzügigen Limits). Also muss ich meinen vertagten Task von heute Morgen doch erst beenden. Dazu mag auch gehören, dass ich durch das ganze Gebäude laufen und mit einem viel gesuchten Kollegen reden muss, um Informationen einzuholen (kollaborieren!). Auch das kann lästig werden. Eventuell stehe ich als Bittsteller oder sogar unwissend da! Das sind aber alles kleine, nur zu menschliche Lässlichkeiten. Im Zentrum des Widerstands befinden sich ganz andere Dinge: Zum einen steht oft das Releasemodell der Umarmung von WiP-Limits entgegen, weil es doch wieder auf monatliche Releases setzt und kleine Contributions einzelner Features nicht belohnt. Dadurch fällt die Einsicht in die Vorteile kleiner Losgrößen in der Verarbeitungskette schwer. Ganz im Gegenteil lieben einige Entwickler es, riesige Berge von WiP vor sich herzuschieben, um in den wenigen Tagen vor dem Release in haarsträubenden Sessions wieder alle losen Enden zusammen zu klauben – was gerne am Wochenende oder gegen 23:00 Uhr geschieht. Das wirkt für einen selbst wesentlich nachhaltiger als ein kontinuierliches, cooles Stück für Stück Ausspielen gerade beendeter Features. Wer würde das schon merken? Welches Risiko bestünde dabei? Welcher Löwe wäre hier zu bändigen? Und schon ist wieder klar, wo die Vorteile der Begrenzung von WiP liegen, wenn es auch noch so unspektakulär wirkt.

Der Hauptgrund aber ist ein ganz anderer. Entgegen der ökonomischen Vernunft lernen ganze Berufsstände, vor allem auch Programmierer, das hohe Lied der Utilisierung, d. h. Vollauslastung aller „Ressourcen“, mit Effizienz zu verwechseln. Wichtig ist dabei, dass jeder etwas zu tun hat und sein „Bestes“ gibt. Eine ordentliche Priorisierung und Fokussierung sind Nebensache und in der Realität der Utilisierung eventuell sogar lästig und ablenkend. Tatsächlich kann man schnell feststellen und leicht nachspielen, dass ein Fokus auf die jeweils wichtigsten Features und deren konsequente Abarbeitung – dann durch geringe WiP-Limits nach Little’s Law auch in geringer Lead Time – den größeren ökonomischen Vorteil bringen. Auch bei WiP-Limits beansprucht die Umgewöhnung Zeit und Geduld. Die ersten Einwände beim Einfordern der WiP-Limits können vernichtend ausfallen. Tatsächlich muss mit diesen behutsam umgegangen werden, um die Idee der WiP-Limits nicht zu „verbrennen“.

Pull bietet also einen automatischen Überlastschutz gerade für Teams in einem Umfeld, das über das Kanban-Board sehr transparent ist. So ist es auch die Aufgabe von Prozessverantwortlichen oder Coaches, die Regeln des Pull zu etablieren und zu schützen. Denn im Affekt wird aus Pull sehr schnell Push. WiP-Limits helfen in diesem Zusammenhang, die Anzahl angefangener Arbeiten klein zu halten und somit die Vorteile geringer Losgrößen zu nutzen. Das sind u. a. kurze Feedbackzeiten, effiziente und fokussierte Übergaben zwischen Bearbeitern und wenige offene Enden. Vor allem aber führt die Verringerung des WiP zu einer einfachen Koordination, somit weniger Koordinationskosten und dadurch geringerer Overheadkosten. Schließlich werden also im Ergebnis Teams und Tasks durch Pull geschützt, Fokus und geringe Koordinationskosten sowie schnelle Lieferzeiten durch WiP-Limits erreicht.

Geringe Transaktionskosten werden vor allem durch technische Exzellenz in den Disziplinen automatisierte Tests, Builds und Deploys erreicht, die unabhängig von Kanban zu betrachten sind, dies aber durch einen Fokus auf kleine Losgrößen stark unterstützen. Eine weitere Reduzierung der Gesamtkosten wird durch die iterative Verbesserung des Flows durch kontinuierliche Analyse des Prozesses sowie Anpassung und vor allem weitere Verringerung der WiP-Limits erreicht. Da Flow nicht nur ökonomisch günstig ist, sondern auch Spaß macht, kann Kanban nach einer Gewöhnung an WiP-Limits und Pull bei entsprechender Begleitung schnell auf große Akzeptanz stoßen und damit den unökonomischen Fokus auf Utilisierung verdrängen.

Werden beide Konzepte allerdings nicht konsequent beachtet, so bietet Kanban keine Chance zum Beobachten der zentralen Probleme und ihrer Diskussion. Dann bleibt von Kanban nur Kanban-But übrig. Und wenn das funktioniert, hätte das Team auch mit vielen anderen beliebigen Cargo-Kult-Prozessen funktioniert. Wahrscheinlich werden in diesen Teams auch keine regelmäßigen Retrospektiven durchgeführt. Schade um die verpasste Chance der kontinuierlichen Verbesserung durch Kanban!

Markus Andrezak leitet „Architektur und Prozesse“ bei mobile.de, wo er maßgeblich an der Einführung von Scrum und Kanban beteiligt war. Kontakt: mandrezak[at]team.mobile.de
Geschrieben von
Markus Andrezak
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.