Mehr "Flow" im Workflow mit WIP-Grenzen

Work-in-Progress-Grenzen sollen nicht etwa deinen Fortschritt begrenzen, ganz im Gegenteil.

Dan Radigan Dan Radigan
Browse topics

Was sind WIP-Grenzen?

In der agilen Entwicklung legst du mit Work-in-Progress-Grenzen (WIP-Grenzen) die maximale Menge von Aufgaben fest, die in jedem Status eines Workflows vorhanden sein dürfen. Durch die Begrenzung der Work-in-Progress-Aufgaben können Unzulänglichkeiten im Workflow eines Teams leichter erkannt werden. Engpässe in der Delivery-Pipeline eines Teams werden deutlich sichtbar, bevor eine Situation problematisch wird.

Warum sind WIP-Grenzen wichtig?

Du möchtest jetzt bestimmt mehr wissen (das hoffe ich zumindest!).

WIP-Grenzen steigern den Durchsatz und verringern die Menge der "fast erledigten" Aufgaben, da das Team gezwungen ist, sich auf eine kleinere Auswahl an Aufgaben zu konzentrieren. Grundlegend fördern WIP-Grenzen eine Kultur des "Erledigens". Noch wichtiger ist aber, dass WIP-Grenzen Blockaden und Engpässe sichtbar machen. Wenn klar ist, welche vorhandene Aufgabe einen Engpass verursacht, können sich Teams um solche blockierenden Probleme kümmern, um diese zu verstehen, zu bearbeiten 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.

Bei der Entwicklung lassen wir uns leicht dazu verleiten, einen Vorgang auf Eis zu legen und mit einem anderen anzufangen. Wir müssen dann jedoch zwischen zwei verschiedenen Kontexten wechseln oder Aufgaben an Teamkollegen übertragen. 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 auf halbem Weg etwas Neues zu beginnen (und wieder nicht abzuschließen). WIP-Grenzen ermutigen uns also, unseren eigenen Arbeitsfluss nicht zu behindern.

Außerdem verdeutlichen WIP-Grenzen, in welchen Bereichen chronische Untätigkeit oder auch andauernde Überlastung herrscht. Das Team kann mit ihrer Hilfe Ineffizienzen im gesamten Prozess statt nur in dem Bereich sehen, in dem es gerade arbeitet.

Profitipp:

Für Teams, die WIP-Grenzen noch nicht kennen, werden sie sich etwas seltsam anfühlen. Nehmt euch die Zeit, sie in den ersten Iterationen zu besprechen. Ihr solltet verstehen, wann und warum das Team die WIP-Grenzen erreicht. Widersteht zunächst der Versuchung, die Grenzen beliebig anzupassen. Wenn ständig gegen die Grenzen verstoßen wird, ist entweder die WIP-Grenze zu streng oder der gesamte Prozess des Teams ineffizient.

Verwenden von WIP-Grenzen in agilen Teams

Nachdem du jetzt vom Wert der WIP-Grenzen überzeugt bist, kommen wir nun 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.

WIP-Grenzen | Atlassian Agile Coach

Im obigen Screenshot wurde eine WIP-Grenze für den Code-Review festgelegt. Der Hintergrund der Spalte ist rot, da sie die Grenze überschreitet.

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

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 noch Kapazität für weitere Arbeit vorhanden ist. 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ß er, dass er sich nun Code-Reviews zuwenden oder einen anderen Entwickler unterstützen kann.

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 Entwicklerteam 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 Agile-Board oben bedeutet, dass das Team zu viele Code-Reviews angesammelt hat.

Anti-Pattern, die vermieden werden sollten:
  • WIP-Grenzen werden bei Bedarf erhöht, damit das Team nicht mehr daran anstoßen kann (klingt "Verschuldungsgrenze" irgendwie vertraut?).
  • Die Teammitglieder haben größere "Nebenaufgaben", um Zeiten zu überbrücken, in denen sonst nichts zu tun wäre.
  • Teammitglieder warten untätig darauf, dass mehr Arbeit eintrifft, statt sich um Engpässe zu kümmern.
  • Es werden lieber mehr Arbeitsstunden für dauerhafte Engpässe bereitgestellt, statt Entwicklungsverfahren oder Teamprozesse zu verbessern. 

4 Ziele für agile Team, die WIP-Grenzen verwenden

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. Wenn 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 Aufgaben konsistent ein. Bei der Unterteilung von Anforderungen und User Storys sollten einzelne Aufgaben auf höchstens 16 Stunden Arbeit begrenzt werden. Damit kann das Team Aufgaben zuverlässiger einschä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.

Profitipp:

Wenn WIP-Grenzen für das Team funktionieren, verkürzt sich die Durchlaufzeit für Vorgänge. Die Durchlaufzeit ist die Zeit, die bis zum Abschluss eines Vorgangs vergeht. Weitere Informationen findest du auf unserer Seite zu Agile-Metriken.

Ziel 2: Ordne WIP-Grenzen den Kompetenzen des Teams zu. Im obigen Beispiel wird davon ausgegangen, dass die 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 Arbeitsfluss 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 Aufgaben ü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.

Weiter geht's
Kanban vs Scrum