Wat zijn WIP-limieten?
In agile ontwikkeling bepalen WIP-limieten de maximale hoeveelheid werk die kan bestaan in elke status of toestand van een workflow. Het beperken van de hoeveelheid werk in uitvoering maakt het gemakkelijker om inefficiëntie in de workflow van een team te identificeren. Knelpunten in de leveringspipeline van een team zijn duidelijk zichtbaar voordat een situatie escaleert.
Waarom zijn WIP-limieten belangrijk?
Nu denk je vast: "Vertel me meer!" (Althans, dat hoop ik in ieder geval.)
WIP-limieten verbeteren de doorvoer en verminderen de hoeveelheid werk die 'bijna klaar is', door het team te dwingen zich te concentreren op een kleinere reeks taken. Op fundamenteel niveau stimuleren WIP-limieten een cultuur van 'done'. Belangrijker is dat WIP-limieten blockers en knelpunten zichtbaar maken. Teams kunnen zich dan richten op geblokkeerde issues om deze te begrijpen, implementeren en afsluiten als er een duidelijke indicator is van welk bestaand werk een knelpunt veroorzaakt. Zodra blokkades zijn weggenomen, begint het werk in het hele team weer te stromen. Deze voordelen garanderen dat waardeverhogingen sneller aan klanten worden geleverd, waardoor WIP-limieten een waardevol hulpmiddel zijn in agile ontwikkeling.
Tijdens de ontwikkelingsfase kun je nog wel denken: "Oh, ik stop even met deze issue en ga aan een andere issue beginnen." Als je twee issues open hebt, betekent dit van context schakelen tussen twee verschillende dingen of werk overdragen tussen teamgenoten. Even geen aandacht besteden aan de ene issue en een andere issue oppakken, is niet zonder consequenties: het kost tijd en vermindert de focus. Het is bijna altijd beter om de oorspronkelijke issue helemaal af te maken in plaats van aan een nieuwe issue te beginnen en de andere te laten liggen. Met andere woorden, WIP-limieten ontmoedigen ons om onze eigen workflow te belemmeren.
Ten slotte identificeren WIP-limieten gebieden van chronische nietsdoen of overbelasting. Ze helpen het team inefficiënties te zien in het hele proces in plaats van alleen het specifieke gebied waarin ze werken.
Voor teams die onbekend zijn met WIP-limieten, zal het eerst wat ongemakkelijk voelen. Neem de tijd om ze in de eerste paar iteraties te bespreken. Begrijp wanneer en waarom het team de WIP-limieten heeft bereikt. Weersta de verleiding om ze meteen maar willekeurig aan te passen. Als een inbreuk consistent wordt, is dat een teken dat ofwel de WIP-limiet te restrictief is of dat het proces van het team inefficiënt is.
WIP-limieten gebruiken voor agile teams
Nu je WIP-limieten op hun waarde weet te schatten, is het tijd om spijkers met koppen te slaan.
Bepaal bij het uitrollen van een nieuwe workflow als team de WIP-limieten voor elke status. We raden aan om WIP-limieten in te stellen nadat het gemiddelde aantal werkitems in elke status gedurende enkele sprints is gecontroleerd. Hieronder zie je een voorbeeld van een agile bord met WIP-limieten die worden gebruikt door een doorsnee softwareontwikkelingsteam.
Hierboven is een WIP-limiet ingesteld voor codereview. Omdat de kolom de limiet overschrijdt, is de achtergrond rood geworden.
Aangezien er niets meer te doen is zodra een issue is opgelost, is er geen WIP-limiet nodig. In het bovenstaande kanban-bord betekent 'Te doen' dat de story volledig is doorgelicht door de producteigenaar en het team. Het ontwikkelingsteam verplaatst werk uit de kolom 'Te doen' naar de kolom 'In uitvoering' zodra het team aan de slag gaat met werkitems. Als best practice is het belangrijk om voldoende werk in de status 'Te doen' te houden, zodat elk lid van het ontwikkelingsteam volledig benut blijft. Door maar net genoeg story's in de status 'Te doen' te houden, loopt de producteigenaar niet te ver op de feiten vooruit als het gaat om het uitwerken van vereisten, en reageert het programma beter op verandering.
De kolom 'In progress' geeft een overzicht van werk dat in actieve ontwikkeling is. In dit geval is het doel van WIP-limieten ervoor te zorgen dat iedereen werk te doen heeft, maar niemand hoeft te multitasken. Op het bord hierboven is de limiet voor items 'in uitvoering' 4 en zijn er momenteel 3 items met die status. Het team kan hieruit aflezen dat ze de capaciteit hebben om meer werk aan te nemen. Als best practice stellen sommige teams de WIP-limiet lager in dan het aantal teamleden. Het idee hierachter is om ruimte vrij te houden voor goede agile praktijken. Als een ontwikkelaar een item voltooit, maar het team al aan de WIP-limiet zit, weten ze dat het tijd is om een paar codereviews te doen of een andere ontwikkelaar te helpen met het schrijven van code.
De status 'codereview' is bedoeld voor stories die volledig zijn geschreven, maar die moeten worden nagekeken voordat ze worden samengevoegd in de codebasis. Tijdige codereviews of codebeoordelingen zijn een best practice die kwaliteit garanderen, nieuwe innovatie sneller op de markt brengen, samenvoegingen gemakkelijker maken door open branches te verminderen en kennis binnen het engineeringteam verspreiden. Items in deze toestand vereisen dringend actie, en wel om een paar redenen:
- De kwaliteit van de code stagneert als teamleden nieuwe code inchecken
- De ontwikkelaar verliest de bij het schrijven van de oorspronkelijke code opgedane context
- De functie kan worden samengevoegd in de hoofd-branch voor release
WIP-limieten garanderen dat niet-beoordeelde code zich niet opstapelt.
Op het bord hierboven heeft het team te veel codebeoordelingen, waardoor de kolom rood is gemarkeerd om dit aan te geven.
- WIP-limieten worden indien nodig verhoogd, zodat ze niet meer worden bereikt door het team. ('Schuldplafond' iemand?)
- Iedereen heeft een grote 'achtergrondtaak' op zijn bordje om iets te doen te hebben op momenten waarop ze anders duimen zouden zitten draaien.
- Teamleden zitten rustig te wachten tot er meer werk naar ze toekomt, in plaats van zich bezig te houden met het oplossen van knelpunten.
- Het toekennen van extra persoonsuren bij aanhoudende knelpunten heeft de voorkeur boven verbeteringen in engineeringwerkwijzen of teamprocessen.
4 doelen voor agile teams die WIP-limieten gebruiken
Zoals elke nieuwe activiteit, kunnen WIP-limieten in het begin ongemakkelijk aanvoelen. Het doel hier is om het team op middellange termijn te optimaliseren, en de ongemakkelijkheid op korte termijn is eigenlijk een goede zaak. Het zorgt ervoor dat het team wat pijnpunten voelt in hun proces. Nadat het team gedurende enkele weken heeft kunnen wennen aan de ingestelde WIP-limieten, voer je indien nodig aanpassingen door. Weersta de verleiding om een WIP-limiet te verhogen puur en alleen omdat het team de limiet blijft bereiken. Grijp in dat geval de kans om de capaciteit te vergroten - idealiter door het team op te leiden en elk lid nieuwe skillsets te geven of door een aspect van het ontwikkelingsproces efficiënter te maken.
Doel 1: Een uniforme grootte hanteren voor individuele taken. Bij het opsplitsen van vereisten en userstories is het belangrijk om individuele taken te beperken tot maximaal 16 uur aan werk. Dit verhoogt het vermogen van het team om met vertrouwen inschattingen te maken en helpt knelpunten te voorkomen. Niets vertraagt een team en verergert WIP-limieten zo erg als een groot werkitem dat de pipeline verstopt.
Wanneer de limieten voor werk in uitvoering goed zijn afgesteld voor het team, zal de cyclustijd van een issue afnemen. Cyclustijd is de hoeveelheid tijd die nodig is om een issue af te sluiten. Bekijk onze pagina over agile statistieken voor meer informatie.
Doel 2: WIP-limieten in overeenstemming brengen met de vaardigheden van het team. In het bovenstaande voorbeeld wordt ervan uitgegaan dat teamleden vergelijkbare skillsets hebben. Als jouw team specialisten heeft kunnen de limieten voor werk in uitvoering verschillen wanneer de specialist erbij betrokken is. Definieer een status die specifiek is voor het werk van de specialist. Als er knelpunten ontstaan in die status, maak dan van de gelegenheid gebruik om andere teamleden op te leiden om extra capaciteit toe te voegen voor de vaardigheden van de specialist en de doorstroming binnen het hele team te vergroten.
Doel 3: Inactiviteit terugdringen. Als teamleden niets te doen hebben moedig je ze aan een upstream- of downstream-teamlid te helpen. Ze dragen dan bij aan de algehele productiviteit van het team en leren onderweg ook nog iets!
Doelstelling 4: Een duurzame engineeringcultuur beschermen. Limieten voor werk in uitvoering betekenen niet dat ontwikkelaars hun werk moeten afraffelen om overbelasting van het werk in een bepaalde status te voorkomen. Ze zijn bedoeld om solide, agile engineeringwerkwijzen te ondersteunen die de kwaliteit van het product en de gezondheid van de codebasis beschermen.
Als je team klaar is om WIP-limieten in te voeren, gebruik dan onze sjabloon voor een kanban-bord om gratis aan de slag te gaan.
