Nietig: wanneer de ceremonie niets verandert
De vierde vorm van mislukking bij agile theater: het gebrek aan opvolging. Wanneer de retro alleen maar woorden oplevert, een uitlaatklep wordt voor problemen waar het team geen invloed op heeft, en hoe men in plaats daarvan prioriteiten moet stellen, zaken moet escaleren en ervan moet leren.
De meest rampzalige vorm van mislukking is niet een slechte ceremonie. Het is juist een goede ceremonie die niets verandert.
Een stand-up kan worden vastgelegd, een planningssessie kan volgepropt worden, 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 — en dan 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 botter: „Ik heb nog nooit iets anders zien gebeuren dan woorden.” Dit is de meest herhaalde klacht over retrospectives die er bestaat, en het is niet de klacht die de advieskringen in onze sector denken dat het is.
Woorden, en niets dan 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 vervolgens daar voor altijd is blijven liggen, terwijl de volgende retrospective er weer drie nieuwe opleverde. „Ik heb dezelfde retrospectieve punten sprint na sprint herhaald zonder dat ze werden aangepakt”, luidt een berustend verslag. „Dit actiepunt zal niet worden aangepakt. Dat is best triest.” Volgens een veel geciteerd onderzoek voltooit slechts ongeveer een derde van de teams consequent hun retro-actiepunten — en de overige twee derde leert, sprint na sprint, dat de ceremonie woorden oplevert, en niets anders dan woorden. Wees echter voorzichtig met deze anekdotes: onze eigen gegevens over welk percentage van de actiepunten uit de retrospectieve daadwerkelijk wordt uitgevoerd wijzen op een uitvoeringspercentage van bijna drie op de vier — en laten zien dat verantwoordelijkheid en ritme, en niet de inspanning, bepalend zijn voor de kloof.
De oplossing die daadwerkelijk werkt, bestaat niet uit meer actiepunten, maar uit 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. Stel te veel actiepunten vast en de helft wordt niet uitgevoerd — en die helft die niet wordt uitgevoerd, leert het team dat het allemaal niet telt. Eén punt, waarvoor iemand verantwoordelijk is, met een evaluatiedatum, sluit de cirkel die een lange lijst open laat. Het hoofdstuk Waarom retrospectives mislukken in onze retro-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
Maar er bestaat een diepere vorm van deze leemte, en dat is precies waar het advies uit onze sector de plank volledig mis slaat. Soms worden de acties niet uitgevoerd omdat het team er nooit toe in staat zou zijn geweest om ze te realiseren — omdat de werkelijke problemen nu eenmaal buiten het bevoegdheidsgebied van het team vallen. 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 om 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 hetzelfde als de ideeënbus de schuld geven van het feit dat het management de suggesties niet leest.” U kunt zich niet uit een machtsprobleem faciliteren. 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“ — en 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 maant 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 echte 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 schouwspel. 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 dat is in de huidige editie gebeurd. In de tweede editie van Agile Retrospectives (2024), waarin David Horowitz zich bij Esther Derby en Diana Larsen voegde, werd een heel hoofdstuk toegevoegd over kwesties die buiten de controle van het team vallen — de pijn werd zo acuut dat de standaard dit eindelijk 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: waar het team zeggenschap over 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 — bij grote, hardnekkige problemen moet u dat deel vinden waarmee het team nu al 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 altijd 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 dat de voortgang ervan 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 van de tweede editie — en het is een opluchting om dit uit de officiële bron 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 toetst met een evaluatiedatum — in plaats van een taak die wegrot 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 wat het resultaat is“ is een experiment. “De implementaties verbeteren” is een plakbriefje dat in de vergetelheid raakt.
Het benadrukt ook een kostenpost die nooit op lijsten met anti-patronen voorkomt: de emotionele belasting van een sessie die puur uit is op het lucht geven. Zoals een deelnemer het verwoordde, kan een retro „meer dan een uur duren waarin men daar zit en voornamelijk luistert naar andere mensen die over dingen klagen, wat mij somber stemt.” Een retro die uitsluitend uit het luchten van frustraties 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; het is om ze een uitweg te bieden: zet de rode punten om in experimenten met een verantwoordelijke, een datum en een verspreidingsplan, en dat uur is niet langer een plek waar frustratie alleen maar rondcirkuleert.
Dat is de weg uit de leegte en uit de handleiding. Zorg ervoor dat de cyclus kort genoeg is om deze te sluiten, voer de triage eerlijk genoeg uit om zaken die het team niet kan oplossen door te geven, en meet wat er wordt geleerd 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 slechts uitgevoerd?
Veelgestelde vragen
Wat doet u als bij elke retro weer 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 opgeschreven maar nooit door iemand is opgeëist, blijft deze in de backlog liggen terwijl er tijdens de volgende retro nog drie nieuwe bijkomen — beperk het tot één opgeëist item met een evaluatiedatum, en begin de volgende retro met het controleren daarvan. Als het probleem steeds terugkomt omdat het daadwerkelijk buiten de controle van het team valt, zal het opnieuw op de lijst zetten nooit werken: sorteer het op basis van wie er verantwoordelijk voor is en escaleer het naar een hoger niveau met vermelding van naam en datum, in plaats van opnieuw uw frustratie te uiten.
Wat doet u als het echte probleem buiten de invloedssfeer van het team ligt?
Zorg ervoor dat u het team niet aanmoedigt om kleinere problemen aan de orde te stellen — zo verandert een retrospectieve in een schijnvertoning. Beoordeel elk probleem op basis van wie er daadwerkelijk verantwoordelijk voor is, escaleer vervolgens de kritieke kwesties naar een hoger niveau met vermelding van een naam en een datum, en maak ze zichtbaar op een retrospectief-bord, zodat ze niet stilletjes terzijde kunnen worden geschoven. Binnen uw invloedssfeer blijven is slecht advies wanneer dit betekent dat de echte belemmering wordt verdoezeld.
Hoe zorgen we ervoor dat retrospectieve actiepunten daadwerkelijk worden afgehandeld?
Beperk het tot één. Eén enkele verbetering waar het team zich daadwerkelijk 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-actie waarbij de vakjes worden afgevinkt, voordat het team het opgeeft.
- Hoe creëert u een psychologisch veilige omgeving — openhartigheid die een uitweg vindt.
- De retrospectieve Eerste Richtlijn — de norm die ervoor zorgt dat iedereen zich aan de regels houdt.
- 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 faalmodi, gedefinieerd.