Een Planning In Scrum: Dat Is Toch Helemaal Niet Agile?

Een Sprint planning voor een Scrum team dat in sprints van 2 weken werkt, duurt volgens de Scrum Guide 4 uur. En dat roept bij teams vaak discussie op. Waarom zouden we zoveel tijd verdoen aan het maken van een planning? Bovendien: binnen Scrum en Agile werken doen we toch niet aan planning? Dat is helemaal niet wendbaar!

 

Wanneer is deze discussie hoor, weet ik dat ik als Scrum Master nog wel even bezig ben met mijn opdracht. De regel “reageren op verandering boven vasthouden aan een plan” uit het Agile Manifesto wordt er veelvuldig bijgehaald. Als een soort bewijs dat een planning in Scrum niet nodig is.

 

In dit artikel wil ik jou als Scrum Master of Product Owner in het MKB de handvatten geven om jouw team mee te nemen in de mooie wereld van het maken van planningen en het inspelen op verandering. 

 

Reageren op veranderingen boven vasthouden aan een plan

 

In het Agile Manifesto is dit 1 van de 4 waarden: reageren op veranderingen boven vasthouden aan een plan. Een zin dit best vaak tot een heel verkeerde opvatting leidt: het idee dat er binnen een Agile of Scrum omgeving geen planning gedaan wordt.

 

Laat ik beginnen met het ontkrachten van die mythe. Er staat in deze waarde namelijk nergens benoemd dat er geen planning gedaan wordt! Er wordt enkel gesteld dat reageren op verandering belangrijker gevonden wordt dan vasthouden aan een gemaakte planning.

 

En dat is iets heel anders! Dat haalt niet de noodzaak van een planning weg. Het zegt enkel dat als het plan niet goed uit blijkt te pakken of we ontdekken dat de omgeving veranderd, we niet stug door blijven gaan met iets waarvan we al weten dat het niet gaat werken.

 

Het gaat dus niet om het maken van een planning, maar het eraan vasthouden - of eigenlijk loslaten - wanneer we ontdekken dat het niet meer werkt. Ook binnen een Agile en Scrum omgeving is het nog steeds belangrijk een planning te maken.

 

Waarom een planning een goed idee is

 

Stel dat je ergens naartoe moet. Je bent bijvoorbeeld in Eindhoven en moet naar Groningen toe. Je gaat naar de reisplanner van het openbaar vervoer en vraagt de route op. De reisplanner geeft aan dat je eerst naar Utrecht moet, daar moet overstappen naar Zwolle om daar de trein naar Groningen te nemen.

 

Als je wel eens met de trein reist, hoef ik jou niet te vertellen dat dit soms anders uit kan pakken. Helaas, de trein van Utrecht naar Zwolle is uitgevallen. Dus je besluit om een halfuurtje te wachten en de rechtstreekse intercity naar Groningen te pakken.

 

Hoewel je een plan gemaakt hebt, pas je deze tijdens het uitvoeren daarvan aan. Je ontdekt op Utrecht Centraal pas dat de trein naar Zwolle is komen te vervallen. Toch zorg je er wel voor dat je zo snel mogelijk weer terug komt naar het doel wat je hebt: naar Groningen.

 

Dit is precies wat er bedoeld wordt met “Reageren op verandering boven vasthouden aan een plan”. Als je vast had gehouden aan het idee dat je via Zwolle naar Groningen had gemoeten, dan had je misschien wel 2 uur op Utrecht Centraal staan wachten. Je ‘reisproject’ had dan veel meer vertraging opgelopen dan het kiezen van een alternatieve route.

 

Plannen binnen Scrum

 

Binnen Scrum en Agile is dat precies hoe een planning werkt. Natuurlijk kunnen we een plan niet even snel uit een OV-reisplanner halen, daar komt daar iets meer bij kijken. De principes zijn echter wel hetzelfde!

 

Om te beginnen wordt er vaak een groot plan gemaakt voor de ontwikkeling van een product of dienst. Er wordt soms wel meer dan een jaar vooruit gekeken om te bepalen wat het doel is dat behaald moet worden. Let op: ik heb het hier over het doel dat we willen behalen, niet de stappen die we uit willen voeren!

 

Vaak wordt er, op basis van dat doel, een korter plan gemaakt van bijvoorbeeld 3 maanden. Er worden subdoelen bepaald die vervolgens leiden tot milestones. Ook hierbij weer een belangrijke kanttekening: de milestone gaat niet over het werk dat op een bepaald moment af moet zijn, maar een doel wat op een bepaald moment gehaald moet zijn.

 

Binnen Scrum gaat het team vervolgens aan de slag om een plan te maken voor een kortere periode. Een plan voor de komende Sprint. Dit plan wordt door het Scrum team uitgevoerd. Omdat een plan tijdens een sprint, in de praktijk vaak 2 of 3 weken, nog best lang is om aan vast te houden, doet het team iedere dag een Daily Scrum. Tijdens die bijeenkomst maakt het team een plan voor die dag. Een plan voor de komende dag die helpt om het doel van de Sprint te realiseren.

 

De planning bij Scrum gaat daarbij niet om het werk dat afgerond moet worden, maar om het behalen van het doel. Om een goede planning te kunnen maken is het dus van belang een helder doel te hebben voor de Sprint.

 

Stel je voor dat je op Utrecht Centraal staat en niet weet waar je naartoe wilt. Hoe weet je dan welke trein je moet pakken? Door een duidelijk doel te hebben, ben je in staat om tijdens de uitvoer van het plan, beslissingen te nemen om het plan aan te passen.

 

Conclusie

 

Na het lezen van dit artikel weet je dat “reageren op verandering boven vasthouden aan een plan” iets anders betekent dan “we maken geen plan”. Het betekent vooral dat we wendbaar blijven en inspelen op onverwachte situaties in plaats van stug doorgaan met iets waarvan we weten dat het toch niet gaat werken.

 

Als Scrum team is het daarbij uiterst belangrijk een helder doel te hebben. Teams die geen helder doel hebben voor hun product of Sprint herken je vaak aan de items op hun Sprint Backlog. Deze beschrijven taken die uitgevoerd moeten worden in plaats van doelen die behaald moeten worden.

 

Vaak is het doel van zo’n team om de taken op het bord weg te werken. In dat geval is er natuurlijk geen reden om je plan aan te passen gedurende de uitvoer. Of je daarmee ook de juiste dingen doet valt natuurlijk te betwijfelen.

 

Een belangrijke tip om jouw Sprints te voorzien van een helder, aanpasbaar plan, is te beginnen met een helder doel. Beantwoord daarvoor de vraag “Wat wil ik deze Sprint bereiken?”, en zoek daar de User Stories bij.