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?
Jetzt denkst du sicher: "Ich will mehr wissen!" (Nun, 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 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.
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 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.
- WIP-Grenzen können bei Bedarf erhöht werden, damit das Team die Grenzen nicht mehr erreicht. (Ist der Begriff der Schuldengrenze bekannt?)
- Die Teammitglieder haben sich große "Nebenaufgaben" zugelegt, 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 Personenstunden für dauerhafte Engpässe bereitgestellt, als Verbesserungen an Entwicklungsverfahren oder Teamprozessen vorzunehmen.
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. 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.
Wenn WIP-Grenzen für das Team funktionieren, verkürzt sich die Durchlaufzeit für einen Vorgang. Die Durchlaufzeit ist die Zeit, die bis zum Abschluss eines Vorgangs erforderlich ist. 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 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.
