Gedachten naar aanleiding van een PI-planning

Ik had onlangs het geluk aanwezig te mogen zijn bij een Program Increment-planning - kortweg: PI-planning. Het was de tweede die mijn werkgever ooit organiseerde, en de eerste waar ontwikkelaars bij aanschoven. Het was een hele ervaring. En ik zal in wat volgt kort reflecteren op die ervaring.

Dit is een goed moment om een disclaimer in te bouwen, denk ik. Want ik pretendeer absoluut niet de waarheid van deze sessie te vangen of verkondigen! Als de ervaring (en het lezen van Voskuils Het Bureau) me één ding geleerd heeft, dan is het wel dat iedereen zijn eigen perspectief heeft op wat er gebeurt op een kantoor, en dat die perspectieven elkaar diametraal kunnen tegenspreken.

Ik zie deze blog daarom meer als aanleiding om te reflecteren op wat algemene organisationele tendensen - zoals bezien vanuit deze hoek. Als blijkt dat mijn blik de waarheid geweld aan heeft gedaan, dan is dat maar zo. Laat ik voor de vorm beweren dat het is om de identiteit van de betrokkenen te beschermen. - Heb ik mezelf dan genoeg ingedekt?

SAFe

Ik kende het concept van een PI-planning niet (en puristen zullen na de komende alinea’s vast zeggen dat ik het nog steeds niet ken), maar van wat ik ervan begrepen heb, is het een meeting waarin Scrum-teams en businessstakeholders samen kijken naar wat ze het komende kwartaal op denken te gaan leveren.

De PI-planning is een idee dat over is komen waaien uit het Scaled Agile Framework - kortweg: SAFe. Ik heb wel eens wat gehoord van SAFe, en van wat ik ervan begrepen heb, is het een variant op Scrum voor grote organisaties die wel Agile willen zijn (of, cynischer: zichzelf Agile willen kunnen noemen) maar het nog niet helemaal aandurven.

Op basis van de meeting die ik mee heb gemaakt, durf ik te menen dat een PI-planning inderdaad prima in een SAFe omgeving past.

De opzet

Maar voordat ik ik daar op inga, is het misschien een goed idee om kort uiteen te zetten hoe mijn werkgever de PI-planning vorm heeft gegeven.

We begonnen de dag met een voorstelrondje - want nog niet elke ontwikkelaar had kennisgemaakt met elke stakeholder. Vervolgens zette de directrice kort uiteen wat haar visie voor het bedrijf op langere termijn was. Daarna hielden enkele afdelingshoofden een praatje over wat de businessdoelen op kortere termijn zullen zijn. De Product Owners (PO’s) mochten daarna nog kort uiteen zetten wat er het afgelopen kwartaal allemaal was bereikt - en, ook niet onbelangrijk, wat er nog op tafel lag.

Vervolgens werd de groep opgesplitst per Scrumteam. (Hoewel, niet precies per Scrumteam. Maar daar kom ik nog op terug.) Mijn team - althans: een deel ervan - parkeerde zich in een vergaderzaal met enkele stakeholders en een groot whiteboard met daarop de komende zes Sprints. Aan ons de taak om de door de relevante afdelingshoofden geschetste doelen te plotten op de komende zes Sprints - voor zover mogelijk, uiteraard. Daarnaast werd ons gevraagd om de afhankelijkheden en risico’s per Sprint inzichtelijk te maken. Voor deze hele exercitie hadden we twee sessies van vijftig minuten de tijd.

Aan het eind van de dag kwamen de verschillende teams bijeen. Hun individuele output werden samengebracht op één groot whiteboard. Zie daar: dat wat de organisatie het komende kwartaal op gaat leveren, netjes in één overzicht. Succes! Het kost je een hele dag, maar dan heb je ook wat.

Grote groepen

Hoewel, het is maar wie je het vraagt, natuurlijk. Een collega van me was van mening dat dit geen meeting was waar hij bij aanwezig had moeten zijn. Natuurlijk, gaf hij toe, een PI-planning zonder enige inbreng van een softwareontwikkelaar is verspilde moeite. Maar het aanhaken van een voltallig team was weer het andere uiterste. De ontwikkelaars in een team zouden volgens hem zoveel mogelijk beschermd moeten worden tegen alle politiek die bij een planning komt kijken. De PO en een softwarearchitect of teamlead, meer zou er volgens hem niet aan hoeven haken.

En er zit wat in die kritiek. Er schuilt een gevaar in grote groepen, en dat is dat het discussies in een kakofonie van meningen doet verzanden. Niet voor niets luidt de vuistregel: bij een lineaire toename van het aantal deelnemers neemt het nut van een discussie kwadratief af. En er schuilt een gevaar van een compleet ontwikkelteam tegenover een groepje stakeholders te zetten, en dat is dat ze de stakeholders door hun aantal - let op: niet door hun argumenten! - gaan overstemmen. Wat dat betreft is zijn suggestie om alleen een architect of teamlead aan te haken, volstrekt begrijpelijk. Dat zorgt ervoor dat de stem van het team gehoord wordt, zonder dat het per se de discussie hoeft te domineren.

Wendbaarheid

Een andere collega had een diepgravender kritiek op de meeting. Volgens hem ging het tegen de kerngedachte van Agile ontwikkelen in. Die kerngedachte zit al in het woord verpakt: wendbaarheid. Een organisatie die zich voor een heel kwartaal vastlegt, is niet een bij uitstek wendbare organisatie. Want wat doet zo’n organisatie wanneer er een belangrijk nieuw inzicht opgedaan wordt? Het heeft twee keuzes: ofwel het schuift dat inzicht door naar het volgende kwartaal - met alle gevolgen van dien -, ofwel het gooit de planning van dit kwartaal overboord. En als je voor dat laatste kiest, wat heeft een PI-planning dan nog voor zin?

Ook die kritiek snijdt hout. Er valt hooguit tegenin te brengen dat een organisatie die vanuit een watervalfilosofie overstapt op een planning voor maar één kwartaal, al een enorme stap heeft gemaakt. Maar hoe groot is de afstand vanaf daar naar een tweewekelijkse planning - en echte Agility? Het antwoord op die vraag is afhankelijk van de wendbaarheid van de stakeholders en het management - de geestelijke wendbaarheid, bedoel ik. Of: de mate waarin het management het aandurft om de (denkbeeldige?) controle op het proces te laten vieren. Dat is allesbehalve een triviaal vraagstuk.

De Agile gedachte

Over wendbaarheid gesproken: überhaupt valt er nog veel te winnen als het erop aankomt de organisatie vertrouwd te maken met het Agile gedachtegoed. Tijdens de twee opgesplitste planningsessies, bleef het keer op keer belangrijk om te benadrukken dat het team niet beloofde om complete - volledige, tot in de puntjes perfect functionerende - features in dit kwartaal op te leveren. Het beste wat we konden beloven, was een - hopelijk! - minimum viable product (MVP). Het zou vervolgens aan de business zijn om te beslissen: is dit werkbaar en kan het team zich op de volgende feature richten, of moet hier nu nog aan door worden ontwikkeld?

Dat is een grote omslag voor een organisatie die het gewend is om eerst alles tot in de puntjes uit te werken en vervolgens een perfect functionerend product te verwachten. - Dat die verwachting in de afgelopen twintig jaar niet één keer bewaarheid is geworden, is overigens nooit een reden geweest om deze te temperen. De menselijke geest functioneert soms wonderlijk, is het niet?

Schattingen en uren

Die waterval-achtige manier van denken bleek ook in de conclusie die de stakeholders uiteindelijk trokken uit de planningsessies van de teams. Naar mijn beleving waren deze bedoeld om helder te krijgen (a) hoe groot de brokken werk ongeveer waren die we het komend kwartaal op ons bordje kregen, vooral ten opzichte van elkaar; (b) welke blokken het best in welke volgorde konden worden afgewerkt, en (c) of er nog afhankelijkheden waren naar zaken buiten het team bij de implementatie ervan.

Stakeholders trokken een heel andere conclusie: voor dit en dat brok hebben we dus zoveel uur nodig. In mijn beleving veranderde de schatting die het team aan de ene kant van de vergaderruimte uitsprak, in de korte periode dat het door de lucht zwierde richting het oor naar de stakeholder, in een commitment over hoeveel uur bepaalde features ons gaan kosten. Het idee dat je relatieve schattingen - dat brok functionaliteit kost ons zeker één Sprint, dat brok is groter: drie Sprints - om kunt zetten in zoiets precies als werkuren, is naar mijn idee volslagen ongeloofwaardig. Maar misschien is dat omdat ik niet over budgetten ga, wie weet. Het gaf de planning voor mij wel een wat ongemakkelijke nasmaak.

Gedeeld begrip

Dat ik de PI-planning desondanks een succes noemde, heeft niet alleen te maken met mijn opgewekte persoonlijkheid (of ironische levenshouding). De cultuur van mijn werkgever is van oudsher een eilandencultuur. Teams spreken nauwelijks met elkaar - en de bovenste lagen van het management spreken nog minder met de werkvloer. De PI-planning bood een mooie gelegenheid om deze impasse te doorbreken. Daarin zijn volgens mij grote stappen gezet.

Het voorstelrondje aan het begin van de dag was er bijvoorbeeld niet alleen voor de aardigheid. Het was de eerste keer dat ik de hogere regionen van het management in levende lijve en met mijn eigen ogen zag. En je bleek er nog mee te kunnen praten ook!

En dat is belangrijk, want het beeld van het management en de teams bleek niet altijd op één lijn te liggen. Eerder gaf ik aan dat de groep werd opgesplitst per Scrumteam. Maar ik had beter kunnen zeggen: per wat-het-management-als-Scrumteam-zag. Want een deel van mijn eigen team werd weggesnoept, stiekem met de bedoeling om de legacy-applicatie die we uit proberen te faseren, nieuw leven in te blazen. Ons team hield ons immers toch sowieso al met die applicatie bezig?

Ja, was het antwoord van de ontwikkelaars, maar toch niet zo. Tijdens hun twee-keer-vijftig-minuten heeft dat deel van het team zich er dus hard voor gemaakt om hun businessdoelen te bereiken met de inzet van ons greenfield-project. Geen gemakkelijke opgave, maar het proberen toch zeker waard! (En, zo bleek later, niet zonder succes!)

Praten

In het Agile-manifest staat de zinsnede: mensen en hun onderlinge interacties boven processen en hulpmiddelen. Een PI-planning is een hulpmiddel, en onderdeel van een proces, dat is waar. Maar het heeft ons - ontwikkelaars, stakeholders, managers; mensen dus - er wel in gefaciliteerd met elkaar te gaan praten. Dat is de enige manier waarop er echt een gedeeld begrip kan ontstaan.

En dan zal ik volgens puristen vast nog steeds niks weten over PI-planningen, maar er is in elk geval vooruitgang geboekt.

agile ontwikkeling · bedrijfscultuur · communicatie · procesverbetering · program increment-planning · scaled agile framework (safe) · scrum · vergaderen