Kanban voor agile teams

Tegenwoordig neemt het gebruik van kanban binnen agile teams enorm toe. En terecht. Ik zie het als de volgende stap om als team voorspelbaar te worden. In dit artikel leg ik heel bondig uit wat kanban is aan de hand van de 5 kanban principes en leg ik uit hoe je start met het combineren van  scrum en kanban.

Kanban en Toyota

Een gerespecteerd en kwalitatief automerk, de Toyota prius zijn wellicht de eerste gedachten. Kanban heeft zijn roots in Japan bij het merk Toyota en het Toyota Production System (TPS). Kanban is een systeem om te organiseren en betekent in het Japans letterlijk “uithangbord”. Dit komt omdat er zwaar gebruik wordt gemaakt van visualisatie. In productiesystemen, zoals bij het maken van auto’s, heeft elk onderdeel op de vloer een visuele kaart waardoor kraakhelder wordt gemaakt waar het onderdeel naar toe gaat, waar het vandaan komt en hoeveel er in de verpakking aanwezig zijn. Deze sticker is de “productie kanban”.

1. Visualiseer de flow van het werk

Begin met het visualiseren van de flow van werk. Gebruik hierbij een UML activiteiten diagram of UML status diagram. Begin met de vraag, wie en wat voor handelingen zijn er nodig om werk “af” (done) te noemen. Denk goed na over de scope van het werk en wanneer werk “af” (done) is. Deze stappen noemen we de definitie van de flow van werk (definition of workflow). Probeer als team te denken als een fabriek om de definition of workflow te bepalen. Dus wie doet wat wanneer.

De meeste scrum teams waar ik observeer zie ik werken met een basis opzet van een workflow. Het proces is verdeeld in to-do, in-progress en done. Overigens een prima start om werk te visualiseren maar er is veel meer mogelijk. Als je met een team developers werkt dan is de acceptatieomgeving wellicht het eindpunt. Een team marketeers kan werken tot het moment dat de campagne live staat en noemen deze status wellicht “done”.

Vraag jezelf af waar de flow van het werk stopt voor jouw team. Streef ernaar dat jouw team alle skills heeft om het werk ook te evalueren en te verbeteren. Zo zie ik graag dat er bijvoorbeeld ook een analyst en een marketeer zijn opgenomen in een development team zodat er echt snelheid gemaakt kan worden. Helaas is dit zelden het geval en wordt het werk overgedragen naar een andere afdeling.

Als dit helder is dan is dit de start van het kanban bord in kolommen. Probeer het bord niet meteen te digitaliseren omdat dit geen interactie tussen teamleden stimuleert en tools ook heel veel beperkingen kennen. Toyota zelf gebruikt hiervoor het argument, “Use visual control so no problems are hidden”. Met andere woorden een bord dat er even niet zo lekker uitziet in Trello kan prima verborgen worden op het scherm als iemand je vraagt naar de hygiëne van het proces. Pas als de definition of workflow volwassen is dan wordt het tijd om te digitaliseren.

2. Limiteer het werk dat in behandeling is

Start met het board gebruiken en probeer te zien waar het werk opstroopt in de kolommen. Als het werk ergens opstroopt in de flow van werk dan heeft dit het effect dat er geen werk wordt afgemaakt. Om dit aan te zetten, de stroom van werk die geleverd moet worden vertraagd en er ontstaan risico’s op kwaliteit. Stel je voor dat er een kwaliteitsissue wordt ontdekt bij werk dat “af” (done) is en dit probleem wordt veroorzaakt in een vroeg stadium van de workflow. Dit defect is dan misschien aanwezig bij al het werk dat in behandeling is.

Om deze bottlenecks te verwijderen moeten we ons limiteren in het werk dat in behandeling is. Dit wordt ook wel WIP (Work In Progress) genoemd. Ultiem is er steeds maar een enkel werkitem in behandeling maar dit is streven. Vaak is het nodig om te schakelen naar een ander item als het team geblokkeerd raakt. Er zijn veel argumenten om het aantal items dat in behandeling is te beperken zoals al eerder genoemd. Het beste argument is een verhoogd team morale. Als iedereen aan een beperkt aantal items werkt en elkaar helpt op een bepaald moment, dan versterkt dit de teamspirit en is het ook nog mogelijk om de stakeholders flexibiliteit te geven over de wensen en eisen van het werk op dat moment in behandeling.

3. Meet en beheer de flow

Nu het kanban systeem is opgezet en het team probeert het werk in behandeling te beperken wordt het tijd om te meten. De flow van werk kan eenvoudig worden gemeten met de wachtrij theorie (queueing theory). Little’s Law is hier goed toepasbaar. Begin te meten wat per dag de “throughput”, het aantal items per dag dat op de “af” (done) kolom wordt geplaatst en tel het aantal items in het systeem. Dit wil zeggen alle werk items die tussen de start en done kolom staan. Met deze twee gegevens is de gemiddelde tijd van een item te berekenen “average leadtime”.

Bijvoorbeeld op de A2 bij Amsterdam zijn er in een uur 200 auto’s aangekomen. Er staan op een moment nog 100 autos op de A2 vanaf Utrecht. De gemiddelde reistijd over dat traject is een half uur (100 auto’s  gedeeld door 200 auto’s per uur). In de spits staan er iets meer auto’s op de snelweg. Stel dat het er 12.000 zijn en er komen 6.000 auto’s per uur bij Amsterdam aan dan is de reistijd opgelopen tot 2 uur.

4. Maak procesbeleid expliciet

Probeer voor iedere kolom (status in de definition of workflow) een maximum te vinden waardoor de flow op gang blijft en voorspelbaar wordt. Schrijf dit nummer boven de kolom en respecteer dit als het gehele team. Dit betekend dat er geen werk meer in de kolom mag worden getrokken als het maximum is bereikt. Het maximum van een kolom kan bijvoorbeeld worden bereikt door de hoeveelheid werk in de volgende kolom waar de bottleneck aanwezig is. Je zult je afvragen wat de teamleden in de kolom gaan doen als het maximum is bereikt? Doe een beroep op de skills van de teamleden. Niemand in een scrumteam is aangenomen om precies een enkele skill toe te voegen.

Er zijn meer techieken om transparantie in de definition of workflow toe te voegen. Zorg er bijvoorbeeld altijd voor dat de datum op een werkitem wordt gelogd. Als je dat per kolom doet kun je inzichten verkrijgen waar de wachttijd of vertraging optreden. Zie hieronder een mooi voorbeeld van Henrik Kniberg waar het bord is verduidelijk met meerdere regels en visualisaties.

In deze stap gaat het erom dat de regels en principes van de workflow transparant zijn en worden omarmd door het team. Vaak zie ik door deze regels gezamenlijk op te stellen met het team hoe sterk de team morale is en waar de uitdagingen optreden in de dynamiek.

5. Continu verbeteren

Gebruik retrospectives in de sprint kadans onder andere om de flow te verbeteren en te stabiliseren. Dit kun je bijvoorbeeld doen door de throughput over een langere tijd te visualiseren. Naast throughput zijn er veel meer methoden om flow en voorspelbaarheid inzichtelijk te maken maar dit is een mooi begin en leert het team om samen te werken door werk in behandeling te limiteren. Definieer dus acties om steeds meer voorspelbaar te worden en borg deze in het proces.

Kanban en agile als training?

Ik ben erg benieuwd wat je denkt over kanban als je dit hebt gelezen. Wist je dat ik een training geef waar al deze principes en nog veel meer worden behandeld?