Mehr "Flow" im Workflow mit WIP-Grenzen

In der agilen Entwicklung legen die WIP-Grenzen (Work-in-Progress-Grenzen) die maximale Menge an Aufgaben fest, die in jedem Status eines Workflows vorhanden sein dürfen. Durch die Begrenzung der WIP-Menge können Ineffizienzen im Workflow eines Teams besser erkannt werden.

Engpässe in der Lieferpipeline eines Teams sind deutlich sichtbar, bevor eine Situation ernst wird. Wenn Teams aller Art sich darauf konzentrieren, Aufgaben zu erledigen, bevor sie mit neuen beginnen, sorgen sie damit für mehr Effizienz, reduzieren Kontextwechsel und erzielen deutlich bessere Ergebnisse.

Jetzt denkst du sicher: "Ich will mehr wissen!"

WIP-Grenzen steigern den Durchsatz und verringern die Menge der "fast erledigten" Aufgaben, da das Team gezwungen ist, sich auf eine kleinere Sammlung von Tasks zu konzentrieren. Grundlegend fördern WIP-Grenzen eine Kultur des "Erledigens".

Noch wichtiger ist aber, dass WIP-Grenzen Blocker und Engpässe sichtbar machen. Wenn klar ist, welche vorhandene Aufgabe einen Engpass verursacht, können sich Teams um diese blockierenden Probleme kümmern, um diese zu verstehen, zu implementieren und zu beheben. Wenn die Blockaden entfernt sind, kann die Arbeit im gesamten Team wieder fließen.

WIP-Grenzen sind ein wertvolles Tool der Agile-Entwicklung, mit dem schneller Mehrwert für die Kunden geschaffen werden kann.

Während der Entwicklung denkst du schnell: "Oh, ich unterbreche diesen Vorgang und fange mit einem anderen an." Aber wenn zwei Vorgänge anstehen, muss der Kontext zwischen zwei verschiedenen Dingen gewechselt oder Arbeit zwischen Teamkollegen übertragen werden. Mit einem Vorgang aufzuhören und mit einem anderen anzufangen, hat einen Preis: weniger Zeit und Fokussierung.

Es ist fast immer besser, erst den ursprünglichen Vorgang abzuarbeiten, statt eine neue Arbeit zu beginnen – und nicht abzuschließen. WIP-Grenzen ermutigen uns also, unseren eigenen Arbeitsfluss nicht zu beeinträchtigen. 

Und schließlich heben WIP-Grenzen Bereiche chronischer Untätigkeit oder Überlastung hervor. Das Team kann mit ihrer Hilfe Ineffizienzen im gesamten Prozess statt nur in dem Bereich sehen, in dem es gerade arbeitet.

Nachdem du jetzt vom Wert der WIP-Grenzen überzeugt bist, kommen wir zur Sache.

Wenn ein neuer Workflow eingeführt wird, sollte das Team die WIP-Grenzen für jeden Status gemeinsam festlegen. Wir empfehlen, WIP-Grenzen festzulegen, nachdem du einige Sprints lang die durchschnittliche Anzahl von Aufgabenelementen in jedem Status überwacht hast. Unten siehst du ein Beispiel für ein Agile-Board mit WIP-Grenzen, die von einem typischen Softwareentwicklerteam verwendet werden.

Im obigen Screenshot wurde eine WIP-Grenze für Code-Review festgelegt. Da die Spalte die Grenze überschreitet, ist der Hintergrund rot gefärbt.

Da nichts zu tun bleibt, wenn ein Vorgang den Status "Done" (Erledigt) erreicht hat, ist für diesen Status keine WIP-Grenze erforderlich. Im oben gezeigten Kanban Board bedeutet "To do" (Zu erledigen), dass die Story vom Produktinhaber und Team vollständig untersucht wurde. Das Entwicklerteam verschiebt Aufgaben aus "To do" zu "In progress" (In Bearbeitung), wenn es die Arbeit an einem Aufgabenelement beginnt. Als Best Practice solltest du stets ausreichend Arbeit im Status "To do" haben, damit jedes Mitglied des Entwicklerteams voll beschäftigt bleibt. Wenn sich immer ausreichend Storys im Status "To do" befinden, kommt der Produktinhaber bei der Ausarbeitung von Anforderungen nicht zu schnell voran und das Programm kann besser auf Änderungen reagieren.

Unter dem Status "In Bearbeitung" sind die Aufgaben aufgeführt, die derzeit aktiv entwickelt werden. Hier sollen WIP-Grenzen sicherstellen, dass alle Teammitglieder Arbeit haben, aber niemand durch Multitasking überlastet ist. Im Board oben liegt die Grenze für Elemente im Status "In Bearbeitung" bei 4 und derzeit befinden sich 3 Elemente in diesem Status. Das Team weiß damit also, dass Kapazität vorhanden ist, mehr Arbeit zu übernehmen. Als Best Practice legen einige Teams die maximale WIP-Grenze unter der Anzahl der Teammitglieder fest. Die Idee ist, genug Platz für gute Agile-Verfahren zu lassen. Wenn ein Entwickler ein Element abschließt, das Team aber bereits die WIP-Grenze erreicht hat, weiß das Team, dass einige Code-Reviews fällig sind oder ein anderer Entwickler für eine Paarprogrammierung einspringen muss.

Im Status "Code-Review" befinden sich Storys, die vollständig geschrieben sind, aber noch reviewt werden müssen, bevor sie in die Codebasis gemergt werden können. Zeitnahe Code-Reviews sind eine Best Practice, die für Qualität sorgt, Innovationen schneller auf den Markt bringt, Merges durch weniger offene Branches vereinfacht und das Wissen im gesamten Entwicklungsteam verteilt. Elemente in diesem Status sollten aus verschiedenen Gründen dringend bearbeitet werden:

• Der Code veraltet nicht, wenn Teammitglieder neuen Code einchecken.

• Der Entwickler verliert nicht den Kontext, den er beim Schreiben des ursprünglichen Codes gewonnen hat.

• Das Feature kann für das Release in den Haupt-Branch gemergt werden.

WIP-Grenzen sorgen dafür, dass sich kein ungeprüfter Code anhäuft. 

Die rote Spalte für Code-Reviews im Board oben bedeutet, dass das Team zu viele Code-Reviews angesammelt hat.

Wie jede neue Aktivität fühlen sich WIP-Grenzen anfangs vielleicht seltsam an. Ziel ist, das Team mittelfristig zu optimieren – und ein kurzfristig seltsames Gefühl ist an sich eine gute Sache, weil es das Team dazu bringt, Problembereiche im Prozess zu erkennen. Nachdem das Team über einige Wochen WIP-Grenzen verwendet hat, können diese nach Bedarf angepasst werden. Widerstehe der Versuchung, eine WIP-Grenze anzuheben, nur weil das Team sie immer wieder erreicht. Nutze die Gelegenheit, um die Kapazität aufzustocken – idealerweise, indem du das Team schulst und jedem Mitglied neue Kompetenzen ermöglichst oder indem ein Aspekt des Entwicklungsprozesses effizienter gestaltet wird.

Ziel 1: Teile den Umfang einzelner Tasks konsistent ein. Bei der Unterteilung von Anforderungen und User Storys sollten einzelne Tasks auf höchstens 16 Stunden Arbeit begrenzt werden. Damit kann das Team Arbeiten zuverlässiger schätzen, und es werden Engpässe vermieden. Nichts bremst ein Team oder beeinträchtigt WIP-Grenzen mehr als ein großes Aufgabenelement, das die Pipeline blockiert.

Ziel 2: Ordne WIP-Grenzen den Kompetenzen des Teams zu. Im obigen Beispiel wird davon ausgegangen, dass Teammitglieder über ähnliche Kompetenzen verfügen. Wenn Spezialisten zu deinem Team zählen, müssen die WIP-Grenzen möglicherweise geändert werden, wenn der Spezialist an Aufgaben beteiligt ist. Erstelle einen Status speziell für die Arbeit des Spezialisten. Wenn in diesem Status Engpässe auftreten, schule andere Teammitglieder, um zusätzliche Kapazität für die Kompetenzen des Spezialisten bereitzustellen und den Fluss im gesamten Team zu steigern.

Ziel 3: Reduziere Untätigkeit. Wenn ein Teammitglied nichts zu tun hat, ermutige es, ein Teammitglied in einem Upstream- oder Downstream-Bereich zu unterstützen. So trägt das Teammitglied zur allgemeinen Produktivität des Teams bei und lernt noch etwas dabei!

Ziel 4: Fördere eine nachhaltige Entwicklungskultur. WIP-Grenzen bedeuten nicht, dass Entwickler Arbeiten überstürzt abschließen müssen, um eine Arbeitsüberlastung in einem bestimmten Status zu vermeiden. Sie sollten solide Agile-Entwicklungsverfahren unterstützen, die die Qualität des Produkts und die Integrität der Codebasis schützen. 

Wenn dein Team bereit ist, WIP-Grenzen zu implementieren, kann es gleich kostenlos mit unserer Kanban Board-Vorlage loslegen.