Nietig: wanneer de ceremonie niets verandert

De meest rampzalige vorm van falen is niet een slechte ceremonie. Het is juist een goede ceremonie die niets verandert.

Een stand-up kan worden vastgelegd, een planningssessie kan overladen zijn, en toch zal het team de wrijving en weerstand blijven voelen. Het gebrek aan opvolging is nog erger omdat het prima aanvoelt. De retro vindt plaats, mensen zijn openhartig, er worden post-its geschreven, iedereen knikt instemmend. Vervolgens begint de volgende sprint en is er niets veranderd. Doe dat een paar keer en u krijgt geen woede; u krijgt iets stillers en verdernietends. Zoals een engineer het op Hacker News verwoordde: „Retrospectieven bieden de mogelijkheid om zorgen te uiten, maar naar mijn ervaring gebeurt er nooit echt iets met die zorgen.” Een ander, nog directer: „Ik heb nog nooit iets anders zien gebeuren dan woorden.” Dit is veruit de meest terugkerende klacht over retrospectieven, en het is niet de klacht die de adviseurs in onze sector denken dat het is.

Woorden, en alleen woorden

De gangbare opvatting is dat teams „vergeten actiepunten op te stellen”, dus de gebruikelijke oplossing is om betere actiepunten op te stellen: zorg dat ze SMART zijn, wijs een verantwoordelijke aan en voeg ze toe aan het bord. Hiermee wordt de werkelijke oorzaak over het hoofd gezien. Het probleem is zelden dat er geen actiepunt is opgeschreven; het is dat het actiepunt wel is opgeschreven, aan de backlog is toegevoegd en daar vervolgens voor altijd is blijven liggen, terwijl de volgende retrospective er weer drie nieuwe opleverde. „Ik heb dezelfde sprint-retrospective punten sprint na sprint herhaald zonder dat er iets mee is gedaan“, luidt een berustend verslag. „Deze sticky zal niet worden afgehandeld. Dat is nogal triest.” Volgens een veel geciteerd onderzoek voltooit slechts ongeveer een derde van de teams consequent hun actiepunten uit de retrospectieve, en leren de overige twee derde, sprint na sprint, dat de ceremonie woorden oplevert, en alleen maar woorden. Ga echter voorzichtig om met deze volkswijsheden: onze eigen gegevens over welk percentage van de actiepunten uit de retrospectieve daadwerkelijk wordt uitgevoerd wijzen op een voltooiingspercentage van bijna drie op de vier, en laten zien dat verantwoordelijkheid en regelmaat, en niet de inspanning, bepalend zijn voor de kloof.

De oplossing die daadwerkelijk standhoudt, bestaat niet uit meer actiepunten. Het zijn er juist minder. Beperk het tot één. Eén enkele verbetering waar het team zich oprecht voor inzet, die helemaal bovenaan de agenda van de volgende retro wordt besproken voordat er iets anders gebeurt, is beter dan een lijst van tien punten die allemaal stilletjes in de vergetelheid raken. Dit is geen nieuw advies: Johanna Rothman heeft in Create Your Successful Agile Project al een enkel punt aanbevolen, dat als een experiment wordt behandeld en in de volgende werkfase van het team wordt ingebouwd. Stelt u te veel actiepunten op, dan wordt de helft niet uitgevoerd, en de helft die wel wordt uitgevoerd, leert het team dat het allemaal niet telt. Eén punt, met een verantwoordelijke en een evaluatiedatum, sluit de cirkel die een lange lijst openlaat. Het hoofdstuk waarom retrospectives mislukken in onze retrospectie-gids behandelt het doorlopen van die cirkel vanuit de ceremonie zelf, en de ‘afvink-retrospective’ in het hoofdstuk Prestaties laat zien hoe de leegte eruitziet voordat het team het volledig opgeeft.

Het drukventiel

Er bestaat echter een diepere vorm van deze leemte, en juist hierin schiet het advies van onze sector tekort. Soms worden de acties niet uitgevoerd omdat het team nooit in staat zou zijn geweest om ze te realiseren: de werkelijke problemen vallen nu eenmaal buiten de bevoegdheid van het team. Budget, personeelsbezetting, afhankelijkheden tussen teams, een architectuurbeslissing die twee niveaus hoger is genomen, een door de verkoopafdeling vastgestelde deadline. Het team kan deze problemen de hele dag opsommen. Het kan er echter geen enkele oplossen. En zo wordt de retro een drukventiel: een plek om stoom af te blazen, zodat het management het gevoel heeft dat er naar het team is geluisterd, zonder dat er een mechanisme is om de situatie waarover geklaagd wordt daadwerkelijk te veranderen.

De meest treffende uitspraak hierover is afkomstig van een ontwikkelaar die op dev.to schrijft, en het is de moeite waard deze volledig te citeren: „De retrospective werd een drukventiel. Een schijn van zeggenschap zonder daadwerkelijke macht.” Hetzelfde essay raakt de kern van een punt dat elke coach ongemakkelijk zou moeten maken: „Facilitering de schuld geven is als de ideeënbus de schuld geven van het feit dat het management de suggesties niet leest.” U kunt zich niet via facilitering uit een machtsprobleem redden. En op Hacker News wordt het nog duidelijker gezegd: een retrospectieve is „een ceremonie zonder daadwerkelijk doel, omdat de diepere kwesties die mensen ter sprake brengen doorgaans buiten de macht van dat team liggen“. Erger nog: „het geeft het management een excuus om zaken niet op te lossen.“

Dit is waar het advies van de meeste leveranciers daadwerkelijk schade aanricht. De standaardlijst met anti-patronen raadt teams aan om „binnen uw invloedssfeer te blijven“ (stop met het aan de orde stellen van zaken die u niet kunt veranderen). Wanneer dit advies wordt gepresenteerd als een disciplineprobleem van het team, is het volkomen verkeerd. Het zegt het team dat het de werkelijke belemmering moet verdoezelen en zich alleen moet bezighouden met de kleine, veilige zaken die het team zelf in de hand heeft – en dat is precies hoe een retro verandert in een comfortabel schijnvertoning. Binnen uw invloedssfeer blijven is slecht advies wanneer het belangrijkste in de ruimte zich daarbuiten bevindt.

Laat het naar buiten stromen, houd het niet voor uzelf

Het goede nieuws is dat de canonieke tekst de correctie al bevat, en wel in de huidige uitgave. In de tweede editie van Agile Retrospectives (2024), waaraan David Horowitz zich bij Esther Derby en Diana Larsen heeft gevoegd, is een heel hoofdstuk toegevoegd over kwesties die buiten de controle van het team vallen. De problemen waren zo acuut geworden dat de standaard dit heeft ingehaald. Drie van de daarin beschreven hulpmiddelen vormen het tegengif voor de drukventiel:

• Cirkels & Soep: sorteer elk probleem op basis van wie er verantwoordelijk voor is, in wat het team onder controle heeft, waar het invloed op kan uitoefenen en wat zich in de „soep“ bevindt, waarop het alleen kan reageren. Dit is triage op basis van verantwoordelijkheid, en het vervangt „blijf in uw cirkel” door „leid elk probleem door naar degene die er daadwerkelijk iets aan kan doen”.
• 15%-oplossingen: zoek bij grote, vastgelopen problemen het deel waar het team nu al mee aan de slag kan gaan, zonder dat daarvoor toestemming van iemand nodig is. Niet de volledige oplossing, maar die 15% ervan die binnen handbereik ligt. Vooruitgang op een klein deel is beter dan stilstand bij het geheel.
• Retrospective ‘radiatoren’: zorg ervoor dat de geëscaleerde kwesties naar buiten toe zichtbaar worden, op een bord dat het management kan zien en waarvan de voortgang in de loop van de tijd wordt bijgehouden. Een radiator is het tegenovergestelde van een klep: een klep laat druk ontsnappen en verbergt deze; een radiator brengt het onopgeloste probleem onder de aandacht totdat iemand met de bevoegdheid om het op te lossen, dit doet. Escaleren de rode punten met vermelding van de naam.

Dat is de strenge lijn waar het onderzoek op wijst, en deze wordt door de canon ondersteund: triage op basis van eigendom, rode punten escaleren op basis van naam en datum, uitstralen in plaats van afreageren. Een retro die dit doet, gaat eerlijk om met macht. Een retro die dit overslaat, is een drukventiel met een facilitator.

Het gaat om het leren, niet om de takenlijst

De laatste herformulering rondt de hele cyclus af. De tweede editie verschuift ook het succescriterium zelf, van actiepunten naar leren. Het standpunt (en het is een opluchting om dit uit de canon te horen) is dat een retro zonder actiepunt geen mislukking is als het team iets heeft geleerd. De eenheid van verandering wordt een experiment: een hypothese die u test met een evaluatiedatum, in plaats van een taak die wegkwijnt in de backlog. „Wij denken dat het werken in paren bij de implementatie ons terugdraaipercentage zal verlagen; we gaan het twee sprints lang proberen en dan kijken hoe het gaat“ is een experiment. „De implementaties verbeteren“ is een plakbriefje dat in de vergetelheid raakt.

Het erkent tevens een kostenpost die nooit op lijsten met anti-patronen voorkomt: de emotionele belasting van een sessie die uitsluitend uit het lucht geven van frustraties bestaat. Zoals een deelnemer het verwoordde, kan een retro „meer dan een uur duren waarin men daar vooral zit te luisteren naar anderen die over dingen klagen, wat mij neerslachtig maakt.” Een retro die uitsluitend uit luchtverfrissing bestaat, lost niet alleen geen problemen op. Het eist ook zijn tol van de mensen die de klachten moeten verwerken. De oplossing is niet om gevoelens te verbieden, maar om ze een uitweg te bieden: zet de rode punten om in experimenten met een verantwoordelijke, een datum en een verspreidingsplan, en dan is dat uur niet langer een plek waar frustratie alleen maar rondcirkuleert.

Dat is de weg uit de leegte en uit de handleiding. Maak de lus klein genoeg om deze te sluiten, voer de triage eerlijk genoeg uit om zaken die het team niet kan oplossen door te geven, en meet het leerproces in plaats van het aantal acties te tellen, want openhartigheid die niets verandert is uiteindelijk geen openhartigheid meer. De vier modi (Prestatie, Macht, Overbelasting en de Leegte) zijn uiteindelijk dezelfde vraag die op vier manieren wordt gesteld: voldoet deze ceremonie aan haar doel, of wordt ze alleen maar uitgevoerd?

Veelgestelde vragen

Wat doet u als bij elke retro dezelfde kwesties aan de orde komen?

Stel vast waarom ze terugkeren, want twee verschillende storingen zien er van binnenuit identiek uit. Als de actie wel is vastgelegd maar nooit door iemand is opgepakt, blijft deze in de backlog wegkwijnen, terwijl er tijdens de volgende retro nog drie nieuwe bijkomen. Beperk het tot één item waarvoor iemand verantwoordelijk is, met een evaluatiedatum, en open de volgende retro door dit te controleren. Als het probleem blijft terugkomen omdat het daadwerkelijk buiten de controle van het team ligt, zal het opnieuw op de lijst zetten nooit werken: sorteer het op basis van wie er verantwoordelijk voor is en escaleer het naar boven met vermelding van naam en datum, in plaats van opnieuw uw frustratie te uiten.

Wat doet u wanneer het werkelijke probleem buiten de invloedssfeer van het team ligt?

Leid het team niet zo dat het slechts kleine problemen aan de orde stelt. Zo verandert een retrospectieve in een schijnvertoning. Sorteer elk probleem op basis van wie er daadwerkelijk verantwoordelijk voor is, escaleer vervolgens de kritieke kwesties naar boven met vermelding van een naam en een datum, en maak ze zichtbaar op een retrospectief-overzicht, zodat ze niet stilletjes terzijde kunnen worden geschoven. Binnen uw invloedssfeer blijven is slecht advies wanneer dit betekent dat de werkelijke belemmering wordt verzwegen.

Hoe zorgen wij ervoor dat actiepunten uit retrospectieve evaluaties daadwerkelijk worden uitgevoerd?

Beperk het tot één punt. Eén enkele verbetering waar het team zich oprecht voor inzet – en die tijdens de volgende retro als allereerste punt wordt besproken, nog vóór al het andere – is beter dan een lijst van tien punten die stuk voor stuk stilletjes in de vergetelheid raken. Wijs er een verantwoordelijke voor aan, stel een evaluatiedatum vast en beschouw het als een experiment met een hypothese, in plaats van als een klusje op een lijstje.

Moet er bij een retrospectieve een actiepunt worden vastgesteld?

Nee, en volhouden dat dit wel zo is, maakt juist deel uit van het probleem. In de tweede editie van Agile Retrospectives wordt het succescriterium geherdefinieerd als ‘leren’, in plaats van ‘actiepunten’: een retrospective waarbij het team daadwerkelijk iets nieuws heeft begrepen, is geen mislukking, alleen maar omdat er geen takenlijst uit is voortgekomen. Voer experimenten uit waaruit u kunt leren, geen taken waarover u zich schuldig zult voelen.

Aanbevolen lectuur

• Macht: wanneer gezag de ceremonie overneemt. Waarom de kwesties die het waard zijn om aan de orde te worden gesteld, zo vaak buiten het bevoegdheidsgebied van het team vallen.
• Voorstelling: de ceremonie die u voor het publiek organiseert. De retro-voorstelling waarbij de vakjes worden afgevinkt, voordat het team het opgeeft.
• Hoe creëert u een psychologisch veilige omgeving. Openhartigheid die een uitlaatklep heeft.
• De retrospectieve Eerste Richtlijn. De norm die ervoor zorgt dat er in de zaal eerlijkheid heerst.
• De sprint-retrospective (de bijeenkomst). De plaats die de retrospectieve inneemt in de cyclus, en de lus die hiermee wordt afgesloten.
• Woordenlijst Agile Theatre. De vier geïntroduceerde faalwijzen, gedefinieerd.