Bij Agile werken komt het concept van Work in Progress (WIP) regelmatig voor. Velen van ons kennen dit vooral uit Kanban—omdat de limiet van onderhanden werk, de Work in Progress limiet vooral als je werkt met een Kanban bord goed transparant te maken is.
Kanban en Scrum liggen dichter bij elkaar dan soms wordt gedacht—het is ook daarom dat het Sprintbord, oftewel de Sprint Backlog, en het Kanban bord vaak met elkaar worden verward. Hoe helpt WIP in Scrum? Helpt het bij de effectiviteit van het team? Dit artikel onderzoekt het belang van WIP-limieten binnen Agile en Scrum. Hiervoor moeten we wel eerst een beeld krijgen van wat WIP is, lees mee!
De term Work in Progress verwijst naar de hoeveelheid werk dat in een team nog niet afgerond is. Het kunnen taken, functies of functieverzoeken zijn die in verschillende stadia van voltooiing zijn. Een van de ideeën achter de WIP limiet is dat er bij ieder teamlid niet teveel werk ligt. Want dan kan iedereen effectief zijn werk doen zonder verlies van focus—want dat laatste zorgt voor vertraging. En multitasken, dat weten we allemaal, maakt dommer dan nodig. Alleen gebruiken we dat laatste weetje te weinig.
Het beheren van WIP in Kanban helpt teams dus om zich te concentreren op het voltooien van taken van hoge waarde voordat ze nieuwe taken oppakken. Door het beperken van de hoeveelheid gelijktijdig uitgevoerd werk, kunnen teams de doorvoer maximaliseren en de doorlooptijden verkorten, waardoor de time-to-market wordt versneld. Dit is het theoretische ideaal waar WIP naartoe streeft; het liefst heb je maar één taak waar je met volle focus aan werkt, afrondt en dan een nieuwe oppakt. One piece flow, zoals dat heet in dit verband.
In Scrum ligt het iets anders. Het hele idee achter Agile werken in Scrum is om de chaos in de hoofden van mensen in een team te beperken door het werk binnen een project steeds op te breken in kleine stukjes—dan kun je steeds iets afmaken in focus. Op die manier kun je steeds MVPs afleveren en reviewen—in plaats van een risicovolle lange doorlooptijd waarbinnen wellicht de verkeerde zaken worden opgeleverd.
In Scrum wordt er op verschillende manieren gewerkt aan wat waardevol is voor de klant, en daarmee impliciet aan de beperking van het aantal zaken die moeten worden afgehandeld voordat iets af is binnen de Sprint. Zo zorgt de Definition of Done (DoD) voor een afbakening van wanneer iets ook echt Done is. Deze definitie kun je als team zo uitgebreid of klein houden als je wilt. Als je het handig aanpakt zitten de overkoepelende eisen van de klant ook in de DOD—en als aan het einden van de Sprint alle items op de Scrum Backlog op done hangen, en aan alle requirements is voldaan—dan bezien we of het gehele sprintdoel inderdaad done is door de DOD. Hiermee is de kwaliteit van het te leveren sprintdoel, het increment, aan het begin van de sprint vastgelegd. Op dat Sprintdoel, en daarom ook impliciet op de items op het bord, daar ligt de commitment van het team op. Niet op meer en niet op minder. Ziedaar een zekere limiet van wat gedaan gaat worden in de sprint.
Wat zou de waarde van een WIP limiet kunnen zijn in Agile? Immers in de Scrum Guide komt de WIP limiet niet voor. En commitment op datgene wat het team kan doen, dat is er door het accoord op de DOD en het Sprintdoel. Wordt dat wel eens overschreden?
Het toevoegen van Items in Scrum. De meeste Developers hebben wel eens meegemaakt dat er tijdens de Sprint een verzoek komt van de Product Owner om toch nog een item toe te voegen tijdens de Sprint, zeker als het item past bij het sprintdoel. De Sprint Backlog is in beheer bij de Developers die commitment hebben op het sprintdoel, en de PO zou in principe nieuwe items moeten bewaren tot de volgende sprint. De Developers werken in focus aan wat ze hebben afgesproken als allerbelangrijkste zaken—en iets moet wel heel belangrijk zijn en passen bij het huidige sprintdoel om nog toe te worden gevoegd. Vaak zal de Scrum Master zal zich hiermee bemoeien en de PO en de Developers coachen op de beste acties.En de sprint wordt opengebroken als de noodzaak er is—en niet bij een klein ad hocje.
Maar ook in zo’n geval helpt het heel erg als bij het team in beeld is of iedereen in het team de limiet heeft bereikt van de hoeveelheid onderhanden werk die ze tegelijkertijd kunnen uitvoeren. Dat is gemakkelijker bij veel kleine taken dan bij veel grote taken. Een klein extra taakje past dan gemakkelijk. Kleine taakjes kunnen gemakkelijker in focus worden afgerond. Het is wat anders als iemand al aan de limiet zit en een grote taak heeft, en het item wat wordt toegevoegd ook van formaat is. De afspraak maken over wat (mogelijk in Story points) de limiet is van ieder teamlid in Scrum is dan echt handig. Logisch toch, tot nu toe?
Bij zowel Kanban als in Scrum geldt voor de limieten op werk: Oefening baart kunst. Overbelasting wordt natuurlijk niet direct voorkomen door goede afspraken of door transparantie–simpelweg omdat je niet bij je de allereerste Sprint al weet hoeveel werk een team eigenlijk aankan. Alles transparant maken vanaf de allereerste planning helpt het team wel er-en dat gaat verder dan een kanban bord of een Sprint backlog.
Scrum Masters willen graag vertrouwen hebben in de teams en goede discussies gedurende de Sprint Planning om overbelasting en overschattingen van wat er kan te voorkomen. Het doel is ook om zo een grotere betrouwbaarheid naar de klanten te krijgen van wat er kan worden geleverd. In Scrum spreek je dan over het algemeen eerder met elkaar over de hoeveelheid Story points die je kunt halen, oftewel de Velocity, bij Kanban gaat het over de WIP limiet—maar de uitgangspunten zijn hetzelfde; de menselijke factor is ook van belang. Dat zien we ook bij het volgende onderwerp: discipline
Het instellen van WIP-limieten per kolom op een Kanban-bord dwingt teams om zich te concentreren op het voltooien van taken voordat nieuwe worden gestart, waardoor bottlenecks worden voorkomen. WIP-limieten lijken makkelijk om in te stellen op een bord, maar blijken in de praktijk moeilijk om er aan te houden. Het vergt namelijk niet alleen de discipline om het Kanban bord goed bij te houden, maar ook actief te signaleren wanneer er een overtreding plaatsvindt. Tegelijkertijd is er altijd wel een goede reden voor een ‘overtreding’ en wordt het mechanisme daardoor minder sterk.
Bij Scrum is ook discipline van het grootste belang bij het beheren van de Scrum Backlog—zonder transparantie weten we niet wat er af is en hoe we ervoor staan—en ligt overbelasting op de loer—zeker bij de meer ervaren teamleden—met als gevaar dat de kwaliteit afneemt. Het gaat daarbij ook over de discipline om tijdens de Sprint Planning echt zaken goed door te spreken. Story points helpen daarbij enorm.
Als we er steeds werk bijkrijgen en de DOD overschrijden, moeten we dan niet gewoon het Sprintdoel en de Definition of Done tussendoor aanpassen? Of de WIP limiet? Dan kunnen we zonder overtreding meer doen? Dit zijn veelgestelde vragen in trainingen. En we antwoorden altijd dit: Dat heeft hetzelfde effect als bij veel post je brievenbus vergroten—de chaos wordt er niet minder van. Het is beter om bij een echte noodzakelijke toevoeging van een item aan de Sprin backlog of op het kanban bord goed te noteren dat er extra werk is toegestaan door het team—en dan in de retrospective overleg te plegen over de eventuele aanpassing van de Definition of Done. Of bij Kanban: van de WIPlimiet.
Gaat het hier bij Scrum dan over een gebrek aan prioritering door de Product Owner? Daar kan het Scrum Team als geheel helpen door samen het verschil tussen Ad Hoc en Crisis taken eens te bezien. Ook is klantgerichtheid soms wel eens klantgezwichtheid—daar kan de Scrum Master bij coachen. De Effectiviteit van het team in het leveren van de waarde voor de klant, die zou er nooit onder moeten lijden, dat is het voornaamste.
In een Agile en Scrum-context , net als in een Kanban omgeving, is het effectieve beheer van de hoeveelheid onderhanden werk essentieel voor het maximaliseren van de productiviteit en het behalen van de gestelde doelen. Door zich te concentreren op het beperken van de hoeveelheid gelijktijdig uitgevoerd werk, kunnen teams hun doorvoer verbeteren, doorlooptijden verkorten en waarde leveren aan klanten. Kanban en Scrum hebben daarvoor hun eigen middelen—maar dat wil niet zeggen dat daar als het noodzakelijk is niet uit geput kan worden. Samen nadenken over een WIP limiet per persoon in een Scrum team kan heel effectief zijn daarvoor, zeker als je overbelaste teamleden hebt. Daarom is het begrijpen van het belang van WIP en het gebruik van Kanban als beheermethode erg nuttig, ook in een Agile en Scrum-werkomgeving.