Agile versus planning

Vaak wordt gesteld dat planning niet past bij een Agile omgeving. Gelukkig ligt dat genuanceerder. De kern van Agile is wendbaarheid, het aanpassen aan nieuwe inzichten. De basis daarvan ligt in de 4^e kernwaarde van het Agile Manifesto: “Inspelen op verandering boven het volgen van een plan”.

Belangrijk is de opmerking die bij de kernwaarden hoort: “Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd”. In de basis erkent Agile dat er waarde zit in planning, maar niet zonder oog voor verandering. Een ouderwetse watervalplanning die ongeacht nieuwe inzichten gevolgd blijft worden, is daarmee niet in lijn. Maar in het populaire SAFe framework is er wel degelijk sprake van een planning voor de komende release (Program Increment): de PI Planning, met als belangrijk element: “Inspect and adapt”.

Conclusie: Agile verbiedt het plannen niet, zolang er maar ruimte blijft voor het inspelen op verandering.

Plannen met drie verschillende horizonnen

In de praktijk heb je voor het goed besturen van een ontwikkelstraat, een planning nodig op meerdere horizonnen. Een werkende invulling daarvan, beschrijf ik hieronder, van korte naar lange termijn: de sprintplanning, de rolling forecast / ruwe sprintplanning en de ruwe releaseplanning.

De sprintplanning

De sprintplanning staat meestal niet ter discussie. Deze is onder andere in het veelgebruikte Scrum framework verankerd. In de praktijk is het vooral van belang om een aantal zaken goed op orde te hebben, om de sprintplanning goed te laten werken. Ten eerste is het verstandig om referentie stories te hebben, zodat de hoeveelheid werk over een langere periode geijkt blijft. Op die manier wordt een betekenisvolle “velocity” bijgehouden en inzicht verkregen in hoe de productiviteit van het team zich ontwikkelt.

Ten tweede is het belangrijk om stories waardevast te houden. Na de start van de sprint worden de punten van een story niet meer aangepast, ook niet als een gedeelte af is en er nieuw inzicht ontstaat (het is meer werk dan verwacht), of als een story niet af is en in een volgende sprint wordt afgemaakt. In het verlengde daarvan krijgen bugs geen punten, dat is immers niet (goed) afgerond werk en voor dat werk zijn de oorspronkelijke punten al geïncasseerd. Veranderingen in de specificaties leiden wél tot nieuwe stories met eigen punten. De nuance is ook hier van belang: als een ander team een bug oplost dat zij niet zelf veroorzaakt heeft, kunnen zij daar wel weer punten voor krijgen. Het blijft een kwestie van gezond verstand.

Als derde en laatste punt is het belangrijk dat de sprint scope vast blijft staan, totdat de volledige sprint succesvol is afgerond. Het team commitment betreft het geheel van items voor die sprint en niet het aantal punten van die sprint. De Product Owner kan wel op elk moment de sprint stoppen en een nieuwe sprint starten. Als de sprintinhoud volledig af is voordat het einde van de timebox is bereikt, kunnen er altijd nieuwe items aan de sprint toegevoegd worden. Deze worden dan toegevoegd aan het commitment. Tijd die daarnaast nog over is, kan worden besteed aan een betere refinement van stories op het backlog.

De rolling forecast / ruwe sprintplanning

Omdat er in een Scaled Agile omgeving meerdere teams aan hetzelfde product werken (SAFe: Release Train) en er vaak afhankelijkheden zijn, is het van belang om over verschillende teams heen, op een termijn langer dan één sprint, vooruit te plannen. In SAFe wordt gewerkt met een release of Program Increment.

Het nadeel van een planning die lang van te voren wordt gemaakt is dat nieuwe inzichten de bruikbaarheid ervan gaandeweg verminderen. Daarom ben ik zelf voorstander van een nog meer iteratieve benadering dan in SAFe: een rolling forecast van ongeveer 1 release periode vooruit. Deze wordt aan het begin van elke sprint opnieuw bekeken en bijgesteld. Ik noem deze planning de ruwe sprintplanning. Hierbij wordt op één niveau hoger dan stories (ook wel features genoemd) voor alle teams in een Release Train over een periode van ongeveer 6 sprints vooruit gepland. Hiervoor organiseer ik dan een aparte planningsbijeenkomst van 1 uur waarin niet alle teams volledig aanwezig hoeven te zijn. Noodzakelijk hierbij zijn de Product Manager, de Product Owners, de Scrum Masters (voor zover zij zelf actief in het ontwikkelproces betrokken zijn) en de Software Architect. Scrum Masters die niet zelf programmeren of testen hierbij betrekken, werkt in de praktijk minder goed. In dat geval is een Lead of Senior Developer een goed alternatief. Het werkt nog beter als de Product Owners ook degenen zijn die de specificaties maken, waarbij de rol van analist/specificeerder gecombineerd wordt met het Product Ownerschap.

Vlak voor de start van een nieuwe release kan de forecast met behulp van een PI planning of een andere methode worden “opgehard” en een (minder zwaar) commitment van meerdere teams krijgen. Externe afhankelijkheden en andere betrokkenen spelen dan een zwaardere rol dan tijdens de rolling forecast. In feite is een release van meerdere teams analoog aan één sprint van één team. Voor features gelden dan vergelijkbare punten zoals beschreven voor stories.

De ruwe releaseplanning

Vaak wordt voor een langere periode dan 1 release (vaak 12 weken of een kwartaal) inzicht gewenst in de planning. SAFe werkt met een Program Backlog met features en enablers. Maar een backlog geeft meestal onvoldoende inzicht in de tijdslijnen. In de praktijk blijkt een ruwe releaseplanning (analoog aan de rolling forecast of ruwe sprintplanning), daar een goed handvat voor te bieden. De features kunnen op het backlog worden voorzien van een schatting. Een praktisch bruikbare eenheid daarvoor is de “teamsprint”, een sprint waarin alle teamleden aanwezig zijn zonder verdere afleiding.

Op basis van historische gegevens kan een productiviteitsfactor worden berekend die rekening houdt met vakanties, opleidingen, ziekte, etc. Het voordeel van deze eenheid is dat de teams zich er een goede voorstelling bij kunnen maken. Ook is deze tijdsgebonden (in tegenstelling tot story points). Bij het schatten van de items op het Program Backlog kan ook het team dat de feature in principe gaat maken worden gekozen. Na de schatting wordt desgewenst een “wens-release” aan elk item gekoppeld. Zo ontstaat een plan voor de komende releases, waarbij elk team weer een vorm van commitment afgeeft op hoog niveau: een verzameling features en enablers. Hierin wordt rekening gehouden met afhankelijkheden. Natuurlijk wordt de ruwe releaseplanning bijgesteld op basis van de laatste inzichten. Idealiter vindt elk jaar, en bij grote of belangrijke veranderingen, een herijking plaats van de releaseplanning. In de praktijk is gebleken dat deze methode, in combinatie met de twee vorige planningen, over een periode van 3 jaar uitvoerbaar is met minder dan 5% afwijking.

Basisprincipes

Voor het slagen van bovenstaande planningsmethodieken is een aantal basisprincipes van belang. Het eerste principe is het voorkomen van “perverse prikkels”. Als je ergens op stuurt, is de natuurlijke neiging van mensen om van het middel het doel te maken. Als je bijvoorbeeld stuurt op velocity, het aantal story points dat per sprint door een team historisch is gerealiseerd, dan kan het gebeuren dat een story point devalueert: wat vandaag 2 punten is, is over 5 sprints 3 punten, zonder reële productiviteitswinst. Vandaar het gebruik van referentie stories.

Een tweede basisprincipe is het belonen van voorspelbaarheid in combinatie met een vorm van commitment vooraf. Belangrijk daarbij is dat de teams blijvend worden uitgedaagd om het maximum te leveren dat realistisch is, zonder hen daarop af te rekenen als het niet lukt. Op een gegeven moment wordt het een uitdaging die de teams zelf aangaan om het plan te halen of zelfs in te halen.

Het derde basisprincipe is “meten is weten”: op feiten gebaseerd sturen, zonder waardeoordeel. Het allerbelangrijkste daarbij, is het gebruik van gezond verstand. Ook in een Scaled Agile omgeving blijft het mensenwerk.

Meer weten over agile?

Heb jij een vraag of een uitdaging waarover je met ons wilt sparren? Neem dan direct contact met ons op. We denken graag met je mee.

Wil je weten of jouw organisatie agile geschikt is of niet, bestel dan ons boekje Agile: Geschikt/Ongeschikt of neem contact met ons op. We gaan graag met je in gesprek over wat jou bezighoudt op agile gebied.