scrum werkzaamheden beter plannen

HERSTEL HET EVENWICHT TUSSEN DEV EN OPS

Een methode die deze Japanners ook bedachten is Kanban: een manier om hiccups in productieprocessen tegen te gaan en flow te creëren. Vertaal je dit naar software ontwikkelen, dan is het een uitstekende manier om impediments te voorkomen. Dat gebeurt onder andere door de hoeveelheid werk in de verschillende productiefases te limiteren. Daarmee creëer je betere planningen die ook echt haalbaar zijn.

Kanban is met name geschikt voor DevOps-teams die regelmatig verstoringen hebben, waardoor plannen vaak lastig is. Hun Sprint backlog wordt dan ‘verstoord’ door onverwachte Ops taken. Kanban kan deze teams helpen om het evenwicht tussen Dev en Ops te herstellen en beter haalbare planningen te realiseren door tijdens de Sprint, in de Daily Standup, meer inzicht te geven.

LIMITEER DE HOEVEELHEID ‘WORK IN PROGRESS’

Hoe werkt dat precies? De basis van Kanban is een planbord waarop je bijhoudt welk werk in welke fase zit. Het is een planbord zoals iedereen dat wel kent, met stickers, magneetjes of digitale plakkers die je van de ene naar de andere fase verhuist als een taak klaar is; ‘done’ in Scrum en Kanban-bewoordingen. Het grote verschil echter tussen een Scrum bord en een Kanban bord is dat je bij Kanban de hoeveelheid werk per fase limiteert. Dat noemen we de ‘Work in Progress’ limit, ofwel WIP limit. Het team bepaalt aan de hand van hun ervaring de gemiddelde tijd die ze nodig hebben om een taak door alle fases te krijgen. Zo stellen ze de limiet vast. Ze monitoren continu of deze WIP limits nog steeds voor de juiste flow zorgen of aangepast moeten worden.

WERK CONTINU DE GROOTSTE BOTTLENECKS WEG

Het werken met gemiddelde tijden is misschien wel het lastigste onderdeel van dit concept, want bij Scrum ben je gewend om per taak in te schatten hoeveel ‘tijd’ je nodig hebt: hoeveel tijd kost het om dit item te ontwikkelen, testen en accepteren? Aan de hand daarvan bepaal je hoeveel werk het team de komende Sprint op zich neemt. Bij Kanban laat je dat los en zijn gemiddelden leidend. Een gemiddelde doorlooptijd wordt vastgelegd in een SLE, Service Level Expectation. De SLE wordt vaak gezet op 85%. Dat betekent dat 85% van de items binnen een bepaalde tijd door het gehele proces lopen.
Die gemiddelden helpen je bij het bepalen van de WIP limits. Een WIP limit van drie betekent dat je nooit meer dan drie items in een bepaalde actieve fase van het productontwikkeltraject mag hebben: bijvoorbeeld drie in ontwikkeling, drie in de testfase en drie in de acceptatiefase. Je kunt een item pas doorschuiven naar de volgende fase, als in die volgende fase ruimte is. Op die manier worden de bottlenecks weggenomen voordat ze een probleem kunnen vormen. Het spreekt voor zich dat deze methode het best werkt in multidisciplinaire teams waar T-shaped collega’s elkaar kunnen helpen.

HOUD RUIMTE IN DE PLANNING VOOR OPS TAKEN

Het is verstandig om in de planning van DevOps teams ruimte te houden voor Ops taken. Dat kan met Kanban op twee manieren. In de eerste plaats zijn er de P1 verstoringen die direct actie vereisen. Voor deze taken kan een aparte ‘swim lane’ worden gecreëerd op het Kanban bord. Hoe breed die baan is – lees: hoeveel tijd hiervoor wordt gereserveerd – wordt bepaald door de gemiddelde tijd die het team in een normale periode aan P1-storingen spendeert. Alle overige storingen krijgen een label – P2, P3, etc.- en worden op basis van die prioriteit toegevoegd aan de backlog; het ‘to do’-bakje. Door zowel bij verstoringen als bij nieuw te ontwikkelen functionaliteiten steeds heel helder aan te geven hoe hoog de prioriteit is, hoeft niet bij iedere verstoring opnieuw een afweging te worden gemaakt wanneer die taak wordt opgepakt. Het item wordt automatisch opgenomen in de planning. Omdat die planning werkt met gemiddelde tijden, kun je op het moment dat zo’n storing een prioriteit krijgt toegewezen al een verwachte tijd aangeven wanneer de storing is verholpen. Hetzelfde geldt voor development werkzaamheden die aan de backlog worden toegevoegd. Je kunt dit bovendien grafisch weergeven, zodat in één oogopslag helderheid ontstaat over de hoeveelheid werk die er ligt en de tijd die dit naar verwachting in beslag gaat nemen.

Meer weten over Scrum met Kanban? Ik heb aan mijn teamleden bij Salves een digitale training gegeven die je kunt bekijken. Interesse? Neem contact op met mij. Dat kan rechtstreeks via [email protected].