Waarom retrospectieven mislukken (en hoe u ervoor kunt zorgen dat die van u echt iets opleveren)

Uw team houdt elke sprint een retro. Mensen komen langs, plakken hun post-its op, knikken bij twee of drie actiepunten en vertrekken weer. Maar er verandert niets aan de manier waarop het werk daadwerkelijk wordt uitgevoerd. Doe dat veertig keer per jaar en u hebt geen gewoonte van verbetering opgebouwd — u hebt een gewoonte opgebouwd om over verbetering te praten. Dat is de mislukkingsmodus die bijna niemand benoemt: geen slechte opzet, maar een ritueel dat steevast woorden oplevert, en alleen maar woorden.

Het standaardadvies beschouwt een mislukte retro als een faciliteringsprobleem — wissel de opzet af, formuleer SMARTere actiepunten, voeg een ijsbreker toe. Soms is dat inderdaad de oorzaak. Meestal is dat echter niet het geval. Wij hebben elders de tien veelvoorkomende retrospective antipatronen in kaart gebracht, en het loont de moeite om deze aan te pakken. Dit hoofdstuk richt zich op de twee tekortkomingen die in de lijst beleefd worden omzeild, omdat juist deze ervoor zorgen dat ervaren ingenieurs retrospectieven als tijdverspilling beschouwen: een macht-probleem en een opvolging-probleem. Geen enkele ijsbreker raakt aan deze kwesties.

De terugkeer naar het verleden die niets verandert, omdat het team daar niet toe in staat is

Dit is de meest fundamentele kritiek op retrospectieven, en het punt waarop onze eigen blogpost over antipatronen de plank misslaat. Wanneer een ontwikkelaar zegt dat „er nooit iets gebeurt”, bedoelt hij meestal niet dat het team vergeten is actiepunten op te stellen. Hij bedoelt dat de problemen die het waard zijn om aan de orde te worden gesteld – personeelsbezetting, afhankelijkheden tussen teams, een implementatiepijplijn die veertig minuten duurt, een deadline die drie niveaus hoger is vastgesteld – werkelijk buiten de bevoegdheid van het team vallen om op te lossen. Zoals een engineer het op Hacker News duidelijk verwoordde, kan een retro „een ceremonie zonder daadwerkelijk doel“ worden, „omdat de diepere kwesties die mensen aan de orde stellen doorgaans buiten de macht van dat team liggen om te beïnvloeden.“ Een ander, in dezelfde discussiethread: „Het geeft het management een excuus om zaken niet op te lossen of niet te luisteren, omdat de retro bedoeld is als uitlaatklep voor klachten.”

Dat is de valkuil. De retro verandert in een ontluchtingsklep — het team krijgt de kans om zich uit te spreken, juist zodat er niets hoeft te veranderen. Mensen luchten hun hart, het management heeft het gevoel dat aan de vereisten is voldaan, en de onderliggende oorzaak blijft onaangeroerd. De facilitator hiervoor de schuld geven is, zoals een ontwikkelaar in een essay schreef, „net zoiets als de suggestiebox de schuld geven van het feit dat het management de suggesties niet leest.” Geen enkele hoeveelheid „zeilboot-versus-zeester”-vergelijkingen zal een team de bevoegdheid geven om een probleem op te lossen waarvoor het nooit de bevoegdheid heeft gekregen.

Ons eerdere advies — „richt u niet langer op zaken buiten uw invloedssfeer” — sluit hier stilletjes aan bij het systeem. Het geeft het team de boodschap mee om de werkelijke belemmering te verdoezelen, zodat het gesprek soepel verloopt. Kies in plaats daarvan voor de strengere aanpak. Sorteer elk probleem op basis van wie er daadwerkelijk verantwoordelijk voor is: waar het team controle over heeft, waar het invloed op kan uitoefenen en waar het alleen maar onder lijdt. Dat is de ‘Circles and Soup’-oefening uit Agile Retrospectives (2e druk) van Esther Derby en Diana Larsen — en het doel van de buitenste ring is niet „negeer deze”. Het is de input voor een escalatie.

Niet alles escaleert, en niet alles is hopeloos. 15% Solutions — de techniek uit de Liberating Structures-methode waarbij wordt gezocht naar de kleinste verandering die het team kan doorvoeren zonder toestemming van wie dan ook — houdt het momentum op de invloedring in stand terwijl de grote belemmeringen geleidelijk worden weggenomen. Maar de eerlijke retro weigert te doen alsof de buitenste ring de schuld van het team is.

De feedback die wordt opgeslagen en tegen u wordt gebruikt

Nu het deel waar geen enkele leverancier over schrijft. Mensen zwijgen tijdens retrospectieven om een reden die concreter is dan verlegenheid: eerlijkheid kan nadelig zijn voor de loopbaan. De angst is concreet en komt tot uiting in echte verhalen. Een ontwikkelaar beschreef hoe feedback uit de retro weer naar boven kwam „tijdens mijn jaarlijkse beoordeling, waar werd opgemerkt dat ik ‘te veel klaag’.” Een ander, wat cynischer: „Ze sparen al die klachten op om ze tijdens uw jaarlijkse bonusbeoordeling boven water te halen.”

Dat is feedback banking — eerlijke input die wordt opgespaard en later tegen u wordt gebruikt — en het is de snelste manier om een retro volledig te ondermijnen. De Scrum Guide beschrijft de sprint-retrospective als het Scrum-team dat zichzelf evalueert. Neem dat letterlijk: het team dat zichzelf evalueert. Waarom zit de persoon die uw functioneringsgesprek ondertekent dan in de kamer aantekeningen te maken? Zijn of haar stilzwijgen is voldoende — niemand die zeggenschap heeft over uw promotie hoeft ook maar een woord te zeggen om u ertoe te brengen uw oordeel te verzachten ten opzichte van wat u anders zou hebben gezegd. Uit het Project Aristotle van Google bleek dat psychologische veiligheid de allerbelangrijkste voorspeller is van teameffectiviteit; de loutere aanwezigheid van een manager is vaak al voldoende om die veiligheid teniet te doen. (We behandelen de mechanismen hiervan in het hoofdstuk over het creëren van een psychologisch veilige ruimte.)

Geef de angst dus een naam en bedenk een oplossing om deze te bestrijden:

• Houd de bevoegdheid tot promotie buiten de vergaderruimte. Deel de overeengekomen maatregelen met de leiding, niet de zitplaatsen. Een team dat wordt belemmerd door de aanwezigheid van een leidinggevende kan geen transparante retrospective houden, en geen enkele faciliteringstechniek kan dit nog redden.
• We zijn het erover eens dat wat er wordt gezegd, binnen de groep blijft. Alleen de acties die het team besluit openbaar te maken, worden daarbuiten bekendgemaakt. Juist daardoor durven mensen zich überhaupt uit te spreken.
• Maak anonimiteit een optie per idee, niet een permanente instelling. Anonimiteit zorgt voor een evenwicht in de machtsverhoudingen en brengt gevoelige kwesties aan het licht; wanneer het als een permanente steunpilaar wordt gebruikt, ondermijnt het het vertrouwen dat u probeert op te bouwen. Laat mensen er zelf voor kiezen wanneer het nodig is.
• Wees voorzichtig met het invoeren van meetcijfers. Objectieve gegevens (velocity, cyclustijd) horen thuis in een retro — maar zodra velocity een doelstelling wordt waaraan het team wordt afgemeten, creëert u een velocity-ratchet, en gaan mensen het cijfer optimaliseren in plaats van de waarheid te vertellen. Dit is de power failure mode die openhartigheid verandert in prestatiedruk.

De leemte in de follow-through — en de herformulering die dit verhelpt

Laten we aannemen dat de problemen met stroomvoorziening en veiligheid zijn opgelost. Retrospectives schieten nog steeds tekort wat betreft de meest terugkerende klacht in de hele discussie: „Tijdens retrospectives kunnen zorgen worden geuit, maar er gebeurt eigenlijk nooit iets met die zorgen.” Of, nog duidelijker gezegd: „Ik heb nog nooit gezien dat er iets anders gebeurt dan dat er woorden worden gesproken.” De berustende toon ervan – „dit knelpunt zal niet worden aangepakt“ – is hoe retrospectieven die steeds weer hetzelfde zijn, van binnenuit aanvoelen. Het is geen verbeelding: volgens een veel geciteerd cijfer van de Scrum Alliance voltooit slechts ongeveer een derde van de teams consequent hun actiepunten uit de retrospectieve. De rest wordt op een whiteboard geschreven en weer gewist. De gangbare opvatting overdrijft de somberheid echter wel — wij hebben hoeveel actiepunten uit retrospectives daadwerkelijk worden uitgevoerd gemeten aan de hand van honderdduizenden daadwerkelijke acties, en het percentage voltooide acties ligt dichter bij drie op de vier, waarbij de frequentie en de verantwoordelijkheid bepalen aan welke kant van de kloof een team terechtkomt.

Twee oplossingen, waarbij de tweede de belangrijkste is.

Probeer allereerst niet alles te willen oplossen. Een retro die tien actiepunten oplevert, voert er geen enkel uit. Beperk u tot één verbeterpunt waar het team zich daadwerkelijk voor inzet, en begin elke retro met het evalueren van dat ene punt van de vorige keer, voordat er nieuwe punten worden geformuleerd. Als dat nog niet is gebeurd, is dat het meest nuttige gesprek in de vergaderruimte. Het zoeken naar een nieuwe opzet is het eerste wat teams proberen en het minst waarschijnlijk dat het helpt — het vervangen van Mad/Sad/Glad door een zeilboot is slechts cosmetisch als de opvolging ontbreekt.

Ten tweede — en dit is de nieuwe invalshoek uit Agile Retrospectives, 2e editie waar de hele categorie naartoe evolueert — moet u ophouden met het actiepunt als het belangrijkste doel te beschouwen. De belangrijkste verschuiving van Derby, Larsen en David Horowitz is dat leren, en niet een voltooide taak, het succescriterium is. Vervang het actiepunt door een experiment: een hypothese die u toetst („als we in paren aan de risicovolle story werken, verminderen we het herwerk”), een datum om het te evalueren, en een eerlijke blik op wat er daadwerkelijk is gebeurd. Een retro die geen afvinkbare actiepunten opleverde, maar het team daadwerkelijk iets heeft bijgebracht, is geen mislukte retro. Die ene stap neemt de klacht „er verandert niets” weg, omdat het doel niet langer een voltooide klus is, maar een verandering die u daadwerkelijk doorvoert.

Stilte is geen onverschilligheid — het is een signaal

Een stillere mislukking: de retro waarbij twee van de acht deelnemers vijf minuten lang praten en de rest uit stilte bestaat, en waarbij geen enkel format of vooraf ingevuld bord dat u probeert iets verandert. Het is gemakkelijk om dit te interpreteren als een team dat niet betrokken is. Meestal is dat echter niet het geval. Stilte tijdens een retro is een signaal, niet het probleem zelf — het wijst op een gebrek aan vertrouwen, een onduidelijk doel of een leiderschapskwestie die mensen niet hardop willen benoemen. Op afstand wordt het nog erger: camera’s uit, microfoons gedempt, geen energie.

Vul de stilte niet op met nog meer vragen. Wissel af wie als eerste het woord neemt. Organiseer voorafgaand aan elke discussie een stille, individuele brainstormsessie, zodat mensen eerst opschrijven wat ze willen zeggen voordat ze het hardop uitspreken — dit biedt bescherming aan introverte personen en aan degenen die niet degene willen zijn die het hardop zegt. Verzamel input van tevoren op asynchrone wijze. Laat mensen een post-it inleveren zonder dat zij dit voor de hele groep hoeven te verdedigen. Het doel is geen levendige vergadering; het gaat om eerlijke gegevens, en eerlijke gegevens komen vaak in stilte tot stand.

De vergaderkosten vormen een reële uitgave, geen excuus

Ten slotte is er de kritiek die de groep die pleit voor „nooit een retro overslaan“ te snel van de hand wijst: retro’s brengen kosten met zich mee. „Het is weer een vergadering in mijn agenda die mogelijk de diepe concentratie verstoort waarin ik me bevond“, schreef een ontwikkelaar — bovenop de stand-up, planning, review en verfijning. Bij korte sprints worden de cijfers genadeloos: teams met sprints van één week omschrijven het wekelijks plannen en de wekelijkse retro als „een last“, en daar hebben zij gelijk in. Vijftig retro’s per jaar bij een ervaren team is geen deugd.

De oplossing is niet om retrospectieven over te slaan, maar om de frequentie ervan af te stemmen op de situatie. Een pas gevormd team dat onder druk staat, heeft baat bij een retrospectief na elke sprint. Een stabiel team dat steeds weer hetzelfde oppervlakkige gesprek voert, geeft aan dat de frequentie niet klopt, niet dat reflectie zinloos is. Schakel over op tweewekelijkse retrospectieven, of organiseer retrospectieven naar aanleiding van gebeurtenissen — na een release, na een storing, na een zware sprint — wanneer er daadwerkelijk iets te evalueren valt. De frequentie is een regelaar, geen gebod. (Dezelfde logica van overbelasting geldt voor elke ceremonie — zie anti-patronen bij stand-ups en de gebrek aan opvolging in onze veldgids ‘Agile Theatre’.)

Los het machtsprobleem op, waarborg de openheid, zorg dat één concreet punt daadwerkelijk wordt opgevolgd en stem het tempo af op de juiste mate, dan is de retro niet langer slechts een uitlaatklep. Het wordt dat ene uur per sprint waarin het team daadwerkelijk zijn werkwijze aanpast — en dat was altijd al de bedoeling. Een online retrospectieve-tool helpt op één specifieke manier: het zet elke overeengekomen verandering om in een bijgehouden actie, zodat de opvolging ook na de vergadering, in de week erna, wordt voortgezet.

Veelgestelde vragen

Waarom verandert er eigenlijk nooit iets na onze retrospectives?

Meestal komt dit doordat de kwesties die er het meest toe doen buiten de bevoegdheid van het team vallen, en de retro geen manier biedt om deze ergens naartoe te sturen. Het bord raakt vol met problemen die het team niet alleen kan oplossen — personeelsbezetting, afhankelijkheden, een defecte implementatiepijplijn — en iedereen vertrekt na het weer te hebben beschreven in plaats van het te hebben veranderd. De oplossing is om elk punt te beoordelen op basis van wie er daadwerkelijk verantwoordelijk voor is, één door het team beheerde verbetering te selecteren om aan te werken, en de punten die buiten het bereik vallen naar boven te escaleren met vermelding van de verantwoordelijke en een datum, in plaats van ze stilletjes te laten vallen.

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

U escaleert het, en dat wordt officieel vastgelegd. Deel de kwesties in in zaken waar het team controle over heeft, zaken waarop het invloed kan uitoefenen en zaken die het alleen maar kan ondergaan (de ‘Circles and Soup’-activiteit uit Agile Retrospectives). Het algemene advies luidt om de buitenste ring te negeren en binnen uw invloedssfeer te blijven. Zo verandert een retro in een schijnvertoning. Maak in plaats daarvan van de punten uit de buitenste ring een zichtbaar verzoek – een ‘Retrospective Radiator’ – waarin de belemmering, de impact en de persoon die actie moet ondernemen worden benoemd, en leg dit voor aan de mensen die hier iets aan kunnen doen. Een retro die alleen problemen aan het licht brengt die het team al kan oplossen, is comfortabel en oneerlijk.

Is het veilig om in een retrospectieve eerlijk te zijn?

Alleen als eerlijkheid geen nadelige gevolgen heeft voor de loopbaan. Ontwikkelaars melden regelmatig dat feedback uit retrospectieve sessies tijdens een functioneringsgesprek weer naar voren komt als bewijs dat zij „te veel klagen”. Als de persoon die beslissingen neemt over promoties in de kamer aanwezig is, of als wat er wordt gezegd wordt bewaard voor later, zwijgen mensen en zeggen zij dat alles in orde is. Bescherm openhartigheid bewust. Houd lijnmanagers die bevoegd zijn voor promoties buiten de sessie, spreek af dat wat er wordt besproken in de kamer blijft en dat alleen overeengekomen actiepunten naar buiten komen, en bied anonimiteit per idee aan in plaats van als een alles-of-niets-regeling.

Zijn retrospectieven tijdverspilling?

Dit is het geval wanneer de enige maatstaf voor succes een afgeronde taak is, omdat de meeste sprints u geen keurig afgerond resultaat opleveren. Bekijk het doel eens vanuit een ander perspectief: een retrospective is geslaagd wanneer het team iets leert dat het meeneemt naar de volgende sprint, zelfs zonder een af te vinken taak, en wanneer er één oprecht experiment wordt uitgevoerd in plaats van tien half afgemaakte taken. Retrospectieven verrichten ook stiller werk – het vroegtijdig aan het licht brengen van spanningen en het samenhangend houden van een team – dat nooit als actiepunt naar voren komt, maar wel degelijk reëel is. Wanneer ze worden beschouwd als een leerritueel in plaats van een takenfabriek, verdienen ze hun plaats.