Een figuurtje in de vorm van een plakbriefje dat een briefje in een hoge doos zonder achterwand stopt, waardoor de briefjes er rechtdoorheen vallen en op een stapel op de vloer terechtkomen.

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 Standup kan worden vastgelegd, een planningssessie kan worden overladen met informatie, en toch zal het team de wrijving en weerstand blijven voelen. Het gebrek aan opvolging is nog erger omdat het prima aanvoelt. De retrospectieve 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 verdervender. 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 adviseurs 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 daar vervolgens voor altijd is blijven liggen, terwijl de volgende retrospective weer drie nieuwe opleverde. „Ik heb sprint na sprint dezelfde retrospectieve punten herhaald zonder dat ze werden aangepakt”, luidt een berustend verslag. „Dit plakbriefje zal niet worden afgehandeld. Dat is best 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 niets dan woorden. Ga echter voorzichtig om met deze anekdotes: onze eigen gegevens over het percentage actiepunten uit retrospectives dat daadwerkelijk wordt uitgevoerd, schatten de voltooiingsgraad op 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 aanbevolen om één enkel punt te kiezen, 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 open laat. Het hoofdstuk ‘Waarom retrospectives mislukken’ in onze retrospective-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 dat is juist waar het advies binnen onze sector de plank volledig mis slaat. Soms worden de acties niet uitgevoerd omdat het team nooit in staat zou zijn geweest om ze te realiseren: de werkelijke problemen liggen nu eenmaal buiten het bevoegdheidsgebied 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 opnoemen. Het kan er echter geen enkele oplossen. En zo wordt de retro een uitlaatklep: een plek om stoom af te blazen, zodat het management het gevoel krijgt dat er naar het team is geluisterd, zonder dat er een mechanisme is om de situatie waarover geklaagd wordt daadwerkelijk te veranderen.

vs feedback in Owner Pressure valve input in, nothing out Radiator pushed out to an owner
Een klep laat net genoeg stoom ontsnappen om niets te veranderen; een radiator schuift hetzelfde probleem door naar een met naam genoemde eigenaar. In het volgende deel wordt het ene in het andere omgezet.

De meest treffende uitspraak hierover is afkomstig van een ontwikkelaar die op dev.to schreef, 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 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 duidelijk gesteld: een retrospectieve is „een ceremonie zonder daadwerkelijk doel, omdat de diepere kwesties die mensen aan de orde stellen 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 adviseert teams 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 alleen moet stilstaan bij 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 wel in de huidige uitgave. In de tweede editie van Agile Retrospectives (2024), waarin David Horowitz zich bij Esther Derby en Diana Larsen voegde, is een heel hoofdstuk toegevoegd over kwesties die buiten de controle van het team vallen. De problemen waren zo acuut geworden dat de standaardwerk hierop inspeelde. 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 beheerst, 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% 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 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 de onopgeloste kwestie onder de aandacht totdat iemand met de bevoegdheid om deze 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 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 toetst 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.

Action item “Improve deploys” backlog words, and only words Experiment EXPERIMENT We think X… Try — 2 sprints Review ▸ a date learned a change you’re running Judge a retro by what it learns, not the to-dos it lists.
Een actiepunt als „implementaties verbeteren“ blijft onbeheerd in de backlog liggen; dezelfde intentie, geformuleerd als een experiment (een hypothese met een evaluatiedatum), is een verandering die het team daadwerkelijk doorvoert.

Het erkent tevens een kostenpost die nooit op lijsten met anti-patronen voorkomt: de emotionele belasting van een sessie die louter uit is op het lucht geven van frustraties. Zoals een deelnemer het verwoordde, kan een retro „meer dan een uur duren waarin men daar vooral zit te luisteren naar anderen die over van alles klagen, wat mij somber stemt.” 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; het is 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. Zorg ervoor dat de lus klein 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 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 slechts uitgevoerd?

Veelgestelde vragen

Wat doet u als bij elke retro weer dezelfde problemen 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 opgeëist, blijft deze in de backlog liggen, terwijl er bij de volgende retro nog drie nieuwe bijkomen. Beperk het tot één item waarvoor iemand verantwoordelijk is, met een evaluatiedatum, en begin de volgende retro door dit te controleren. Als het probleem steeds terugkomt 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 er niet toe om kleinere problemen aan de orde te stellen. Zo verandert een retrospective 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-overzicht, zodat ze niet stilletjes kunnen worden genegeerd. Binnen uw invloedssfeer blijven is slecht advies wanneer dit betekent dat de werkelijke belemmering wordt verdoezeld.

Hoe zorgen wij ervoor dat retrospectieve actiepunten daadwerkelijk worden afgehandeld?

Beperk het tot één. 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’, en niet als ‘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