Zijn retrospectieven de moeite waard? Ons oordeel

Ja — maar niet om de reden waarom de meeste teams ze verdedigen. Een retro verdient zijn plaats door middel van leren en samenhang, niet door een overzichtelijke lijst met actiepunten. Als die van u alleen maar woorden oplevert, ligt het probleem niet bij het ritueel zelf. We nemen de standpunten van de sceptici serieus en trekken onze conclusies.

Ja — maar niet om de reden waarom de meeste teams ze verdedigen. Een retro verdient zijn plaats door middel van leren en teamcohesie, niet door een overzichtelijke lijst met actiepunten. Als uw retro alleen maar woorden oplevert, ligt het probleem niet bij het ritueel zelf. Het probleem ligt bij de uitvoering ervan, en bij het vermogen van het team om daadwerkelijk actie te ondernemen.

“Retrospectieven zijn tijdverspilling” is geen oppervlakkige klacht. Het is de ernstigste kritiek die men op agile ceremonies kan uiten, en een oprechte verdediging moet hierop ingaan, in plaats van er omheen te draaien.

Het argument dat retro’s zinloos zijn

Het bewijs van de sceptici is concreet en overal te vinden. Er worden zorgen geuit, maar er gebeurt niets; hetzelfde notitiebriefje duikt sprint na sprint weer op, met de stille berusting dat er ook deze keer geen actie zal worden ondernomen. Volgens een veel geciteerd onderzoek voltooit slechts ongeveer een derde van de teams consequent de actiepunten uit hun retrospectieve — en zelfs die voorstelling van zaken gaat voorbij aan de diepere oorzaak van het falen. (Voor wat het waard is: de gangbare opvatting is te somber; uit onze eigen gegevens over de vraag of teams daadwerkelijk uitvoeren wat ze tijdens retrospectives besluiten blijkt dat de uitvoeringsgraad dichter bij drie op de vier ligt.)

De diepste kern van de kritiek is machteloosheid. De wezenlijke problemen — budget, personeelsbezetting, afhankelijkheden tussen teams, infrastructuur, beslissingen die twee niveaus hoger worden genomen — vallen daadwerkelijk buiten de bevoegdheid van het team. De retro wordt dus de plek waar die problemen worden benoemd, en niets meer dan dat: het team krijgt wel een stem, maar geen hefboom om in te zetten. Erger nog, het biedt het management een excuus. Er is nu een kanaal voor klachten, dus als er niets verbetert, is dat te wijten aan het feit dat het uitlaatkanaal van het team niet functioneert, en niet aan een probleem dat de organisatie moet oplossen.

Dan is er nog het carrièrerisico, dat op vrijwel geen enkele leverancierspagina wordt genoemd. Wanneer eerlijke feedback wordt opgeslagen en tijdens een functioneringsgesprek wordt aangehaald — waarbij wordt opgemerkt dat men te veel klaagt — leren mensen al snel de les: openhartigheid is een risico. En zelfs het uiten van frustraties zelf brengt reële kosten met zich mee. Een uur lang naar de frustraties van anderen moeten luisteren, sprint na sprint, is op zich al een stille uitputtingsslag.

Dat is een ernstig geval. Een retro die zich zo gedraagt, is erger dan helemaal geen retro, omdat het in een cyclus van twee weken aangeleerde hulpeloosheid in de hand werkt.

Waarom ze nog steeds de moeite waard zijn

Het sterkste argument van de voorstanders is niet dat „actiepunten worden afgehandeld”. Het is samenhang. Zelfs een niet-perfecte retro, gehouden als een vaste, onmisbare ceremonie, draagt meer bij aan het vermogen van een team om samen te werken dan het ontbreken ervan — teams die nooit de tijd nemen om te praten, kampen veel vaker met interne conflicten dan teams die dat wel doen. Het meest veelzeggende verhaal van een ommekeer in deze discussie is dat van de ingenieur die van het vrezen van retro’s naar het ernaar uitkijken ging, en zich realiseerde dat het verschil was dat hij er simpelweg nog nooit een had gezien die goed werd uitgevoerd.

De huidige gangbare opvatting ondersteunt dit. De tweede editie van Agile Retrospectives (2024, met David Horowitz als derde auteur) maakt deze verschuiving expliciet: het succescriterium is leren, niet een checklist met acties. Een retro waarbij het team daadwerkelijk iets heeft begrepen, is geen mislukking omdat er geen ticket uit is voortgekomen. Deze ene herformulering biedt een antwoord op de belangrijkste klacht — want „er is niets veranderd“ is niet langer de enige maatstaf voor de waarde van een retro.

In welke gevallen wij van gedachten zouden veranderen

Er is één specifieke situatie waarin wij een team zouden aanraden te stoppen met het houden van retro’s: wanneer de werkelijke problemen grotendeels buiten hun invloedssfeer liggen, het management geen actie onderneemt naar aanleiding van escalaties, en de bijeenkomst geen zeggenschap heeft en geen follow-up kent. Op dat moment is de retro slechts schijnvertoning, en wij geven er de voorkeur aan dat u het escalatieproces aanpast – of de frequentie terugbrengt tot een realistisch niveau – in plaats van elke twee weken een reflectie te blijven houden. Een machteloze retro is geen neutrale verspilling van een uur; deze ondermijnt actief het vertrouwen.

We zouden ook de frequentie aanpassen, niet de vorm, wanneer een team daadwerkelijk geen nieuwe inzichten meer te melden heeft. Een wekelijkse retro bij een team waar niets is veranderd, verwordt tot een ritueel waarbij alleen maar vakjes worden aangevinkt. Dat is een kwestie van frequentie, en geen bewijs dat retro’s zinloos zijn.

De praktische kant van de zaak

  • Definieer succes opnieuw als een leerproces, niet als een lijst met actiepunten. Streef naar één daadwerkelijke verandering of één gezamenlijk inzicht per retro, en bespreek de resultaten van de vorige sessie aan het begin van deze sessie. Een lange lijst zorgt ervoor dat retro’s veranderen in een schijnvertoning waarbij alleen maar vakjes worden aangevinkt.
  • Sorteer problemen op basis van wie er verantwoordelijk voor is, en escaleer de zaken die buiten de invloedssfeer van het team vallen, met vermelding van naam en datum. Zeg mensen niet dat ze „binnen hun invloedssfeer moeten blijven” als dat betekent dat de werkelijke belemmering wordt verzwegen — breng deze juist naar buiten.
  • Zorg voor veiligheid, want het opslaan van feedback is een reëel verschijnsel. Sluit de autoriteitsfiguur uit wiens aanwezigheid de ruimte tot stilte brengt, houd wat er gezegd wordt binnen de ruimte, en bied anonimiteit aan als optie per idee. Psychologische veiligheid is geen overbodige luxe: uit Google’s Project Aristotle bleek, voortbouwend op het onderzoek van Amy Edmondson, dat dit de allerbelangrijkste factor is voor de effectiviteit van een team.
  • Pas de frequentie aan. Als er wekelijks niets nieuws is om over na te denken, doe het dan om de twee weken. Gedwongen reflectie is op zich al een anti-patroon.

In de Scrum Guide staat dat de retrospective erop neerkomt dat het team zichzelf onder de loep neemt om zich te verbeteren. Zodra de retrospectieve dus aan het team wordt opgelegd in plaats van door het team zelf te worden uitgevoerd, bent u het element kwijtgeraakt dat het de moeite waard maakte om er een uur aan te besteden. Dat is de Void-foutmodus — reflectie zonder dat er iets uit voortvloeit — en het is de fout die het gemakkelijkst te verhelpen is op deze lijst.

Veelgestelde vragen

Zijn retrospectieven tijdverspilling?

Dat is het geval wanneer er alleen maar woorden worden gesproken — wanneer bij elke sprint dezelfde punten aan de orde komen en er niets verandert. Maar de oorzaak ligt meestal bij de opvolging en het vermogen van het team om daadwerkelijk actie te ondernemen, niet bij de bijeenkomst zelf. Een retro die leidt tot nieuwe inzichten en kleine, zelfgestuurde veranderingen is het uur dat eraan wordt besteed zeker waard; een retro die slechts als drukventiel fungeert, is dat niet.

Moet een retrospectieve een actiepunt bevatten om de moeite waard te zijn?

Nee. In de tweede editie van Agile Retrospectives wordt succes geherdefinieerd als leren, en niet als een takenlijst — een retrospective waarbij het team daadwerkelijk iets heeft begrepen, is geen mislukking alleen omdat er geen ticket uit is voortgekomen. Het nastreven van actiepunten omwille van de actiepunten zelf is de reden waarom retro’s verworden tot het afvinken van lijstjes. Streef naar één echte verandering of één gedeeld inzicht, niet naar een lange lijst die voor de helft in de backlog verdwijnt.

Wanneer is het echt niet de moeite waard om een retrospective te houden?

In één specifieke situatie: wanneer de werkelijke problemen grotendeels buiten de controle van het team liggen, het management geen actie onderneemt naar aanleiding van wat wordt geëscaleerd, en de vergadering geen invloed heeft en geen follow-up kent. Een machteloze retro is geen neutrale verspilling van een uur — het ondermijnt actief het vertrouwen door het team te leren dat zich uitspreken niets verandert. Pas het escalatiepad aan of verkort de frequentie tot een realistisch niveau in plaats van elke twee weken een evaluatie te houden. En als het team simpelweg geen nieuwe punten meer heeft om te bespreken, verminder dan de frequentie, niet de bijeenkomst zelf.

Aanbevolen lectuur