Veel mensen kennen enkel Scrum als manier van Agile werken. Dat komt doordat Scrum op dit moment bekender is dan Kanban. Als je in een zoekmachine ‘Agile’ intikt, is de kans groot dat je eerste resultaten over Scrum gaan.
En dat is eigenlijk best jammer, vindt onze Kanban-meester Rob van Wees: “Hoewel Scrum een heel mooi Agile raamwerk is, werkt het niet in alle omstandigheden even goed. Star proberen vast te houden aan de ‘Scrum regels’ werkt vaak niet, –een snufje Kanban toevoegen kan voor grote verbetering zorgen.”
Ongepland werk is lastig voor Scrum
In Scrum plannen teams werk in zogenaamde Sprints; vaste periodes van 1,2,3 of maximaal 4 weken. Het team probeert na de Sprint Planning om het geplande werk binnen de gekozen periode af te ronden. Zo kun je aan het eind van elke Sprint iets opleveren aan de klant, een proces dat je met elke Sprint opnieuw uitvoert.
Als je in een zoekmachine ‘Agile’ intikt, is de kans groot dat je eerste resultaten over Scrum gaan.
Maar wat als je team niet alleen planbaar werk doet maar ook ongepland werk, zoals het afhandelen van incidenten, support-tickets, klantvragen enzovoort? Rob: “Omdat je Scrum-team vooraf plant wat er gedaan gaat worden, lijkt ieder nieuw stukje werk dat binnenkomt een verstoring van die planning te veroorzaken. Veel Scrum-teams die ik begeleid, lopen daarop vast en schieten in de stress wanneer het geplande werk in de knel komt door ongepland werk. Ik hoor dan uitspraken als “de Sprint komt in gevaar” of “we gaan de Sprint niet halen!””
voorbeeld van een typisch Scrum-bord. De rode kaartjes zijn ongepland werk dat tussendoor binnenkomt en opgepakt wordt
Als je bovenstaande situatie herkent, dan voelen je Scrum teams zich bekneld door het raamwerk. Volgens Rob kan juist het juist op zo’n moment de moeite waard zijn om wat Kanban aan Scrum toe te voegen.
Een snufje Kanban helpt je Scrum
Waar Scrum de focus legt op Sprints met plukken gepland werk, focust Kanban zich op het continu managen van de flow van werk. En dat is precies wat je nodig hebt als niet al je werk vooruit planbaar is.
Door Scrum en Kanban samen te gebruiken, creëer je juist meer balans en overzicht.
Kanban doet dit door een pull-systeem van werk te maken door te werken met WIP-limieten: dat zijn limieten op de hoeveelheid werk die een team tegelijkertijd onderhanden mag hebben. Onderhanden werk is al het werk dat gestart is maar nog niet is afgerond. WIP is trouwens een afkorting voor Work In Progress, oftewel: onderhanden werk.
Pas als de hoeveelheid onderhanden werk onder de limiet is gedaald doordat er iets is afgerond, is er weer capaciteit om nieuw werk op te pakken.
WIP-limieten en pull
Rob legt uit: “WIP-limieten instellen op je bord zorgt voor een pull-systeem van werk. Dat wil zeggen: een team kan nieuw werk naar zich toe trekken (pull) op het moment dat er iets is afgerond en het onderhanden werk onder de WIP-limiet is gedaald. Het grote verschil met een push-systeem is dat de capaciteit van een team niet tegelijkertijd wordt overbelast met teveel werk. Daarnaast stellen WIP-limieten je in staat om balans aan te brengen tussen verschillende soorten werk, zoals gepland versus ongepland werk.”
Een bord zonder WIP-limieten.
Op dit bord zie je dat er zonder WIP-limiet op de “Doing” kolom onbeperkt werk binnen kan komen. Vaak wordt dit werk gepusht omdat het urgent is of urgent wordt gemaakt. Dat heeft nare effecten: er wordt teveel tegelijkertijd gedaan waardoor er niets meer af raakt, teams en mensen overbelast worden en de planning van werk onvoorspelbaar wordt.
Een bord met WIP-limiet
Rob: “Op dit bord heb ik een WIP-limiet van 3 op de “Doing” kolom gezet (met een rood omcirkelde 3). Het idee is dat een team pas nieuw werk naar de “Doing” kolom trekt (pull) als er een stuk werk is afgerond, –dan is de hoeveelheid kaartjes onder de ingestelde limiet gedaald. We zeggen dan: het team heeft capaciteit om nieuw werk op te pakken.”
Nu je WIP-limieten snapt, legt Rob uit hoe je ze in Scrum kunt toepassen om balans aan te brengen tussen gepland (Sprint) werk en ad-hoc werk.
Gepland werk en ad-hoc werk balanceren
Rob: “Om een balans te maken tussen gepland werk in je Scrum Sprint en ongepland, ad-hoc, werk dat tijdens de Sprint binnenkomt, kun je bijvoorbeeld een extra horizontale baan (swimlane) op je bord maken voor ad-hoc werk. Je zet daarnaast WIP-limieten op je onderhanden werk, in het bord hieronder simpelweg de “Doing” kolom. Die WIP-limieten zorgen ervoor dat er altijd een vaste verhouding van gepland versus ad-hoc werk is.”
De WIP-limieten kunnen niet voorkomen dat er ongepland werk binnenkomt, maar reguleren wel hoeveel ad-hoc werk er tegelijkertijd wordt uitgevoerd ten opzichte van gepland werk. In het voorbeeld is er dus altijd een verhouding van 2 geplande taken versus 1 ad-hoc taak.
Rob voegt toe: “Natuurlijk moet je zelf experimenteren met de gewenste verhoudingen om te zoeken naar de optimale balans. Dat is in ieder team weer anders en dat maakt het juist zo interessant. Zoals je hierboven zag, kun je Kanban-elementen zoals WIP-limieten als pull-systeem en extra swimlanes voor ad-hoc werk toevoegen aan je Scrum.”
Zo kunnen Scrum en Kanban een heel goed duo zijn, die samen juist voor meer balans en overzicht zorgen.
