Zijn retrospectieven de moeite waard? Ons oordeel
Ja, maar niet om de reden waarom de meeste teams het verdedigen. Een retro verdient zijn plaats door middel van leren en samenhang, niet door een overzichtelijke lijst met actiepunten. Als de uwe 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 die de meeste teams aanvoeren. Een retro verdient zijn nut door het leerproces en de 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 zit hem in de uitvoering ervan, en in 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 doen wat zij in retrospectives besluiten blijkt dat de uitvoering van actiepunten 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 invloed uit te oefenen. 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 de organisatie die dit zou moeten 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 de les snel: 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 uitputting.
Dat is een ernstige kwestie. Een retro die zich zo gedraagt, is erger dan helemaal geen retro, omdat deze 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 de 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 met elkaar te praten, kampen veel vaker met interne conflicten dan teams die dat wel doen. Het meest veelzeggende voorbeeld van een ommekeer in deze discussie is de ingenieur die van het vrezen van retro’s naar het ernaar uitkijken ging, en zich realiseerde dat het verschil simpelweg was dat hij nog nooit had gezien hoe een retro op de juiste manier 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 voortkwam. Die ene herformulering biedt een antwoord op de belangrijkste klacht, omdat „er is niets veranderd“ niet langer de enige maatstaf is 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 controle liggen, het management geen actie onderneemt naar aanleiding van escalaties, en de bijeenkomst geen invloed heeft en geen vervolg krijgt. 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 retro zonder daadkracht is geen neutrale verspilling van een uur; het ondermijnt actief het vertrouwen.
Wij zouden ook de frequentie terugschroeven – niet de ceremonie zelf – 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 waardeloos zijn.
De praktische kant
- Definieer succes opnieuw als een leerproces, niet als een lijst met actiepunten. Streef naar één daadwerkelijke verandering of één gedeeld 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 verdoezeld. Breng het in plaats daarvan naar buiten.
- Zorg voor veiligheid, want het verzamelen van feedback is een reëel fenomeen. Sluit de gezagsdrager uit wiens aanwezigheid de ruimte tot stilte brengt, zorg dat wat er gezegd wordt binnen de ruimte blijft, en bied anonimiteit aan als optie per idee. Psychologische veiligheid is geen overbodige luxe: uit Google’s Project Aristoteles 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 meest oplosbare fout 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 fout 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 de tijd die eraan wordt besteed zeker waard; een retro die slechts als afreactiemogelijkheid fungeert, is dat niet.
Moet een retrospectieve een actiepunt bevatten om de moeite waard te zijn?
Nee. De tweede editie van „Agile Retrospectives” beschouwt succes als een leerproces, en niet als een takenlijst. Een retro 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 zorgt ervoor dat 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 werkelijk niet de moeite waard om een retrospectieve 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 uw mening geven niets verandert. Pas het escalatiepad aan of verminder de frequentie tot een realistisch niveau in plaats van elke twee weken een reflectie te houden. En als het team simpelweg geen nieuwe punten meer heeft, verminder dan de frequentie, niet de bijeenkomst zelf.
Aanbevolen lectuur
- Waarom retrospectieven mislukken (en hoe u ervoor kunt zorgen dat die van u echt iets opleveren): een diepgaande analyse van machteloosheid, feedback die als wapen wordt ingezet en het gebrek aan opvolging.
- Waarom retrospectives een nuttig agile hulpmiddel zijn: een heldere uiteenzetting van het belang van deze bijeenkomst.
- Hoe creëert u een psychologisch veilige omgeving: het tegengif voor het ‘feedbackbankieren’.
- Agile Theatre: de ‘Void’-foutmodus: reflectie zonder vervolgstappen, en hoe u kwesties kunt escaleren die het team niet zelfstandig kan oplossen.
- Retrospectieven in TeamRetro: organiseer er een die tot nieuwe inzichten leidt, en niet alleen maar bij woorden blijft.