Limitiere deinen Work in Progress (WIP)

Hast du zu viele Meetings im Unternehmen? Dann liegt das meist daran, dass du und/oder dein Team an zu vielen Themen arbeitet. Warum passiert das immer wieder? Der Mensch hasst es von Natur aus, Möglichkeiten zu verpassen und daher tendieren wir aus Verlustangst dazu, uns mehrere Optionen offen zu halten. Im Unternehmenskontext heißt das oft: Viele Aufgaben werden gleichzeitig bearbeitet. Leider leidet daran die Geschwindigkeit der Fertigstellung. Im schlimmsten Fall wird nichts fertig, wir hüpfen von Kontext zu Kontext und von Meeting zu Meeting und verlieren dabei kostbare Zeit. Teams schaffen aber mehr, wenn sie sich auf einige wenige Themen konzentrieren. Hier siehst du einen Simulator, der Singletasking und Multitasking vergleicht und die Vorteile von Singletasking veranschaulicht, und hier erfährst du mehr über die negativen Konsequenzen von Multitasking.

Scrum-Teams, die ihren Work in Progress (WIP) limitieren, sind produktiver. Trotzdem scheitern viele Teams genau an dieser Limitierung, weil sie nicht wissen, wie sie anfangen sollen. Daher gebe ich dir einen Workshop-Ablauf an die Hand, mit dem du als ScrumMaster gemeinsam mit deinem Team ein System für die WIP-Limitierung erarbeiten kannst.

Eine Anleitung

1. Board-Spalten definieren: Mit deinem Team setzt du ein Task-Board oder Kanban-Board auf. Dieses sollte den jetzigen Arbeitsprozess widerspiegeln. Fang mit einem Minimum an Spalten an; ins Detail gehen kannst du später noch, wenn die Spalten nicht ausreichen: "Product Backlog", "Ready", "In Progress", "Review" und "Done" (oder "Backlog", "Startklar", "In Arbeit", "QA" und "Ausgeliefert"). Wenn du am Anfang zu viele Spalten wählst, beraubst du dich der Option, die Prozesse iterativ zu verbessern und konditionierst die Arbeitsweise vorab, weil du den IST-Zustand bereits änderst. Lies hierzu auch 8 typische Fehler beim Einstieg in Kanban.
2. WIP-Limits festlegen: Mit dem Team entscheidest du nun die maximale Anzahl an Tasks für jede Spalte. Hier gibt es keine Faustregel. Es ist ein iterativer Prozess. Setz für jede Spalte provisorische Limits fest. Das ideale Limit findest du, indem du Limits immer wieder neu justierst und anschließend misst, welchen Effekt dies auf die geleistete Arbeit in einem Sprint hat. Sieh dir beispielsweise an, wie viele Elemente vor dem Festsetzen von WIP-Limits während des Sprints in einer bestimmten Spalte in Bearbeitung sind. Setz dann das WIP-Limit herunter und beobachte, was passiert.
3. Commitment einholen: Es ist wichtig, dass dein Team die WIP-Limits einhält und sämtliche Arbeit im Board festgehalten wird (z. B. Anfragen außerhalb des Flows, Bugfixes). Das heißt auch, Arbeit darf nur in die jeweilige Spalte gezogen werden, wenn das Limit noch nicht erreicht wurde. Wenn das Maximum in jeder Spalte erreicht ist, unterstützen Teammitglieder mit freier Kapazität andere (grandiose Möglichkeit für Pair-Programming zum Beispiel). Widersteht der Versuchung, neue Arbeit aufzunehmen und Limits während des Sprints zu ändern. Dafür habt ihr die Sprint Retrospektive. Das WIP-Limit zeigt Grenzen auf und „zwingt“ Teammitglieder zur Kollaboration. Wenn ihr eine „Review“-Spalte habt, aber nur eine Halbtagsstelle für Quality Assurance (QA), dann werdet ihr schnell feststellen, dass sich hier Arbeit anhäuft, weil eure drei Programmierer:innen mehr Sachen fertigstellen, als gereviewt werden können. Ein Bottleneck wird sichtbar und eine mögliche Lösung ist, dass du neue Ressourcen für QA anfragst oder andere Teammitglieder die QA-Verantwortliche unterstützen lässt (Pairing, Mobsessions).
4. Messen: Du solltest zwei Werte messen: Durchsatz (throughput) und Durchlaufzeit (cycle time). Durchsatz zeigt, wie viele Elemente während des Sprints fertiggestellt wurden. Durchlaufzeit zeigt, wie lange ein Element im Board war. Tools wie Jira messen dies von selbst. In einem analogen Board kannst du einen Punkt für jeden Tag ans Element kleben. Durch das Senken der Durchlaufzeit wird dein Team flexibler beim Reagieren, und die Planung wird leichter.
5. Verbessere das System: Benutz die beiden Werte (Durchsatz und Durchlaufzeit) für die Sprint Review und Retrospektive. So fällt es dem Team leichter, die Limits anzupassen. Hol Stakeholder und vor allem den PO an Board, um auftauchende Impediments aus dem Weg zu räumen. Zeigt diesen anhand der verbesserten Werte, wie nützlich das Heruntersetzen des WIP-Limits ist und wie sie davon profitieren.

Es ist wichtig, laufende Arbeit zu begrenzen. Ein klares Symptom für zu viele parallele Projekte sind zu viele Meetings. Hilf deinem Team mit einem WIP-Limit, sich nur auf aktuelle Aufgaben zu konzentrieren. Engpässe werden so schneller entdeckt und können behoben werden. WIP-Limits sind praktisch der Türsteher, der nur so viel Arbeit durchlässt, wie dein Team erledigen kann. So verhinderst du die Anhäufung unvollendeter Aufgaben, die sonst die Prozesse überfluten und dazu führen würden, dass Teammitglieder ständig zwischen Aufgaben hin und her springen. So wirkt sich das WIP-Limit positiv auf die Effizienz und die Produktivität deines Teams aus. Probier es aus!

Titelbild: Sibeesh Venu, Unsplash