pexels-photo-321193

Implementeer Kanban in 16 stappen

Kanban is een change management aanpak waarbij een bestaand proces wordt geoptimaliseerd. Het implementeren van Kanban kan heel eenvoudig met behulp van de volgende 16 stappen.

  1. Draagvlak creëren  

De eerste stap gaat over het vinden van draagvlak en om samen tot een gezamenlijk uitgangspunt te komen. Vind overeenstemming over te bereiken doelen.

Binnen Kanban worden vaak de volgende doelen onderkend:

  • Optimaliseer het huidige proces
  • Lever hogere kwaliteit software
  • Verbeter de voorspelbaarheid qua doorlooptijd
  • Verbeter de werknemerstevredenheid
  • Creëer ruimte voor een continue verbetercultuur
  • Versimpel het prioriteringsproces
  • Verhoog transparantie
  • Vind een manier om de volwassenheid en professionaliteit van de organisatie te verhogen
  1. Breng de value-stream in kaart

De value-stream is datgene wat de afdeling of de organisatie, waarvoor Kanban wordt geïntroduceerd, oplevert. Van input tot output. In ons geval gaat het vaak om software, dus zou het kunnen gaan van requirements of ideeën tot werkende software.

  1. Bepaal het punt van input en de bijbehorende up-stream stakeholders

Stel vast waar het werk vandaan komt, hoe het de organisatie binnenkomt en wie daarbij betrokken zijn. Vaak zijn dat business owners, architecten, een marketing afdeling, het management, etc.

  1. Bepaal punt van output en de bijbehorende downstream stakeholders

Bepaal waar de output naar toe gaat en wie de downstream stakeholders zijn. Dat kan een onderhoudsorganisatie zijn, maar ook de klanten of medewerkers die met het resultaat aan de slag gaan.

  1. Bepaal welk type werkitems er bestaan en in welke klassen dit opgedeeld wordt

Een bugfix is niet hetzelfde als een story. Wellicht is het binnen uw organisatie gangbaar om ook onderscheid te maken tussen een technische story en een functionele story. Misschien juist niet. Dan zijn er wellicht ook stories die met de hoogste prio moeten worden opgepakt. Of stories die een vaste opleverdatum hebben, willen ze nog relevant zijn. Dit is per organisatie verschillend. Belangrijk is om hier de verschillende werktypes en, indien van toepassing, classificering van het werk in kaart te brengen.

  1. Analyseer voor elk type de snelheid en hoeveelheid waarmee het binnen komt

Bekijk welk type werk hoe vaak binnenkomt. Dit kan eventueel seizoensafhankelijk zijn.

  1. Ontmoet de up- en downstream stakeholders

Hier wordt vastgesteld hoe en onder welke voorwaarden input en output geleverd gaan worden. Verder worden de volgende punten, punt 8 t/m 11 besproken.

  1. Bespreek policies op capaciteit en bepaal WIP

WIP bepaalt Work in Progress. Er kan bijvoorbeeld besproken worden dat een developer niet meer dan één taak tegelijk uit kan voeren. Zijn er tien developers, is de WIP 10. Wellicht dat er wel eens een taak geblokkeerd raakt, dus met een WIP van 12 zou dat binnen het redelijke opgevangen moeten kunnen worden. Maar misschien is het gebruikelijk dat twee developers samen aan één taak werken. In dat geval zou een WIP van 6 beter zijn.

Ook kan hier de capaciteit besproken worden. Gaan we 30% van onze capaciteit aan bug-fixing besteden? Dan is er een WIP van 2 op BUGS en 4 op stories.

Wellicht worden er prio1 stories onderkent die voorrang krijgen, waarbij geaccepteerd wordt dat de WIP tijdelijk wordt overschreden, maar nooit met meer dan één prio1-story tegelijk.

Door dit met stakeholders af te spreken ontstaat er begrip en kan hier later op teruggevallen worden als de druk toe neemt.

  1. Bepaal hoe de input gecoördineerd gaat worden.

Als er gemiddeld 4 stories per week opgeleverd worden met pieken tot 6 stories per week, zou er wekelijks een buffer tot 6 stories aangevuld kunnen worden. Wellicht is het mogelijk om af te spreken dat elke keer als er een story wordt opgepakt, de buffer binnen twee uur wordt ingevuld met een nieuwe op te pakken story. In dat geval hoeft de buffer niet groter te zijn dan 2. In het algemeen geldt, hoe kleiner de buffer hoe beter. Maar er moet natuurlijk wel sprake blijven van flow.

Wie met Kanban bezig is, leert snel de lead time, de doorlooptijd, te bepalen. Het gaat dan niet om de gemiddelde doorlooptijd, maar de doorlooptijd die met 85% of 95% zekerheid afgegeven kan worden. Stel, de lead time is 6 weken, dan moet de buffer gevuld worden met die story die men over 6 weken nodig heeft. Niet meer, niet minder. Er is met Kanban geen noodzaak om hele lijsten continu te herprioriteren.

  1. Bepaal hoe de releases gecoördineerd gaan worden.

Dit is zeer domein afhankelijk. Betreft het een website met continuous deployment, is dit eenvoudiger dan wanneer het complexe software betreft die gefaseerd uitgerold moet worden inclusief afstemming, trainingen, drukwerk, etc.

In deze stap wordt bepaald hoe de releases gecoördineerd gaan worden. Belangrijk is om te weten dat dit binnen Kanban onafhankelijk gebeurd van hoe de input gecoördineerd wordt.

  1. Bepaal de lead time target per werktype per werkklasse

Een target is geen commitment, een target is een target. Begin met wat extra buffer en gebruik de targets om te zoeken naar verbeteringen om het proces continu te verbeteren en om de variabiliteit terug te brengen en aldus de voorspelbaarheid te verbeteren.

  1. Maak een Kanban bord

Dit is waar veel mensen Kanban van kennen en waar de meesten direct mee beginnen. Maak van elke processtap een kolom. Deel eventueel kolommen op in ‘onder handen’ en de queue voor de volgende kolom. Voeg de WIP-limits toe en hang de post-its op. Eventueel met een kleur per werktype en een swimlane met klasse. Of andersom, net wat het beste past bij het proces.

  1. Optioneel: maak een elektronisch bord

Wanneer er veel op locatie, thuis of met remote teams gewerkt wordt, is een elektronisch bord onmisbaar. Ook bieden elektronische tools hulp middels, zoals het bepalen van de lead time, het genereren van een cumulative flow diagram, etc.

Als er minder remote gewerkt wordt, kan een elektronisch bord ook later worden ingevoerd, als er iets meer ervaring is met Kanban en wanneer stappen gezet kunnen worden qua professionalisering. Of het kan achterwege blijven.

  1. Plan de daily stand-up in bij het Kanban bord

In tegenstelling tot Scrum is de DSU – de Daily StandUp – hier geen opsomming van wie wat gedaan heeft en wie wat doet. Dat is immers zichtbaar op het bord. De Kanban DSU bespreekt de taken op het bord van rechts naar links, van boven naar beneden. Wat moet er gebeuren, waar is de WIP-limit bereikt, wie heeft tijd om te helpen, wie ziet verbeteringen en wie heeft tijd om verbeteringen te bestuderen. Uiteindelijk gaat het om het stimuleren van de zogeheten Kaizen-cultuur. De cultuur waarin continu gezocht wordt naar verbeteringen.

Aangezien elke flow een bottleneck heeft, zal elk Kanban-proces mensen moeten hebben die tijd hebben om verbeteringen uit te zoeken of anderen te helpen.

  1. Plan een periodieke retrospective met up- en downstream stakeholders

Plan een periodieke meeting in om de voortgang te bespreken. Laat successen zien en laat zien waar de uitdagingen liggen. Een belangrijk aspect van Kanban is dat iedereen het effect van zijn of haar acties of van het ontbreken van zijn of haar acties direct terugziet in het proces.

Data en cijfers zijn belangrijk in deze meeting. Deze laten zien dat het process en de belangen van de organisatie serieus genomen worden, dat er gezocht wordt naar verbeteringen en dat elke beperking bestaat om de doorstroom te verbeteren.

  1. Leg het team het Kanban bord uit, de WIP limits en het pull systeem

Leer het team hoe het bord moet worden gebruikt. Leg uit wat de WIP limits zijn en dat werk naar binnen getrokken wordt als werk is opgeleverd en niet eerder. Benadruk dat verder niets zou hoeven veranderen. Het proces blijft zoals het altijd is geweest. Als er iets veranderd, gebeurd dat enkel op het verzoek van en in samenspraak met het team zelf. Leg uit hoe gemeten wordt en dat elke verandering, hoe klein of onzeker ook, uitgeprobeerd kan worden omdat het effect direct zichtbaar is.


Dit is Kanban in zestien stappen. Voor meer informatie, neem contact op met Trivento of lees het boek “Kanban: Successful evolutionary change for your technology business” van David J. Anderson.




Aantal
0
shares
0
0