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. Vervolgens verandert er niets aan de manier waarop het werk daadwerkelijk wordt uitgevoerd. Als u dat veertig keer per jaar doet, heeft u 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 bestempelen: een macht-probleem en een opvolging-probleem. Geen enkele ijsbreker raakt deze punten aan. Als het faciliteren daadwerkelijk uw probleem is, ligt de oplossing in het houden van effectieve retrospectieven, niet hier.

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

Dit is de meest ingrijpende kritiek op retrospectieven, en precies het punt waarop ons eigen artikel over antipatronen de plank misslaat. Wanneer een ontwikkelaar zegt „er gebeurt nooit iets”, bedoelt hij meestal niet dat het team vergeten is actiepunten op te stellen. Hij bedoelt dat de problemen die het vermelden waard zijn (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 ingenieur het op Hacker News treffend verwoordde: een retrospectieve kan „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 geacht wordt een uitlaatklep voor klachten te zijn.”

Dat is de valkuil. De retro verandert in een drukventiel: het team krijgt de kans om te spreken, juist zodat er niets hoeft te veranderen. Mensen luchten hun hart, het management heeft het gevoel dat aan de formaliteit is voldaan, en de onderliggende oorzaak blijft onaangetast. De facilitator hiervoor de schuld geven is, zoals een ontwikkelaar in een essay schreef, „net zoiets als de ideeënbus de schuld geven van het feit dat het management de suggesties niet leest“. Geen enkel verhaal over „zeilboot versus zeester“ 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 te lijden heeft. Dat is de ‘Circles and Soup’-activiteit uit Agile Retrospectives (2e druk) van Esther Derby en Diana Larsen. 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 om de kleinste verandering te vinden die het team kan doorvoeren zonder toestemming van wie dan ook, houdt het momentum op de invloedskring 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 in te zetten.”

Dat is feedback banking: eerlijke opmerkingen die worden opgeslagen en later tegen u worden gebruikt, en de snelste manier om een retro te doen mislukken. 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 te laten afwijken van wat u anders zou hebben gezegd. Uit Google’s Project Aristoteles 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 omgeving.)

Geef de angst dus een naam en bedenk een oplossing om deze het hoofd te bieden:

• Houd de bevoegdheid tot promotie buiten de vergaderruimte. Deel de overeengekomen maatregelen met de leidinggevenden, 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 ongedaan maken.
• 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 naar buiten gebracht. 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 ervoor kiezen bij die onderwerpen waarvoor 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 de stroomvoorziening en de veiligheid zijn opgelost. Retrospectieven schieten nog steeds tekort wat betreft de meest terugkerende klacht in het hele discours: „Retrospectieven bieden de mogelijkheid om zorgen te uiten, maar er gebeurt eigenlijk nooit iets met die zorgen.” Of, nog duidelijker gezegd: „Ik heb nog nooit gezien dat er iets anders gebeurt dan woorden.” De berustende toon daarvan („dit knelpunt zal niet worden aangepakt“) is hoe retrospectieven die steeds weer hetzelfde zijn, van binnenuit aanvoelen. Het is geen verbeelding: het cijfer dat iedereen herhaalt – een veel geciteerd gegeven dat slechts ongeveer een derde van de teams hun actiepunten uit retrospectieven consequent afwerkt – blijkt de situatie somberder voor te stellen dan ze is. Wij hebben gemeten hoeveel actiepunten uit retrospectieven daadwerkelijk worden uitgevoerd aan de hand van honderdduizenden daadwerkelijke acties: de voltooiingsgraad ligt dichter bij drie op de vier, en de frequentie en verantwoordelijkheid bepalen aan welke kant van die kloof een team terechtkomt. Waar de volkswijsheid wel gelijk in heeft, is de vorm die het falen aanneemt. Een actiepunt waarvoor niemand verantwoordelijkheid neemt, zonder vaste datum, in een team zonder ritme, is het actiepunt dat op een whiteboard wordt geschreven en vervolgens weer wordt gewist.

Twee oplossingen, waarbij de tweede de belangrijkste is.

Probeer allereerst niet alles te willen oplossen. Hoe langer de lijst, hoe slechter de resultaten per punt: uit onze gegevens blijkt dat bij retro’s die eindigen met tien of meer actiepunten, ongeveer 56% daarvan daadwerkelijk wordt uitgevoerd, tegenover ongeveer 79% bij retro’s die eindigen met één tot drie actiepunten. Beperk het tot één verbeterpunt waar het team zich oprecht aan committeert, neem dit op in de werkzaamheden van de volgende sprint in plaats van het op het bord te laten staan, en open elke retro door het ene punt van de vorige keer te evalueren voordat er iets nieuws wordt vastgesteld. Als dit niet is uitgevoerd, is dat het meest nuttige gesprek in de ruimte. 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: beschouw het actiepunt niet langer als het belangrijkste. Dit is de nieuwe invalshoek uit Agile Retrospectives, 2e editie waar de hele categorie naartoe evolueert. De belangrijkste verschuiving van Derby, Larsen en David Horowitz is dat leren, en niet het voltooien van een 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 retrospectief dat geen afvinkbare actiepunten opleverde, maar het team daadwerkelijk iets heeft bijgebracht, is geen mislukt retrospectief. Die ene stap maakt een einde aan de klacht dat „er niets verandert”, omdat het doel niet langer een afgeronde klus is, maar een verandering die u daadwerkelijk doorvoert. Johanna Rothman paste deze vervanging al toe lang voordat het tot de standaardpraktijk van retrospectives behoorde, in Create Your Successful Agile Project: één punt, uitgevoerd als een experiment, waarbij het volgende werkblok van het team zo wordt opgezet dat het dit punt omvat.

Stilte is geen onverschilligheid: het is een signaal

Een stillere mislukking: de retro waarbij twee van de acht deelnemers vijf minuten lang het woord voeren en de rest uit stilte bestaat, en waarbij geen enkele werkwijze of vooraf ingevuld discussieformulier 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 leiderschapsprobleem dat mensen niet hardop durven te 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 een asynchrone manier. 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 naar voren.

De vergaderkosten vormen een reële uitgave, geen excuus

Ten slotte is er de kritiek die de voorstanders van „sla de retro nooit over“ te snel van de hand wijzen: retro’s brengen kosten met zich mee. „Het is weer een vergadering in mijn agenda die mogelijk mijn diepe concentratie verstoort“, schreef een ontwikkelaar. Dat komt bovenop de stand-up, planning, review en verfijning. Bij korte sprints worden de cijfers genadeloos: teams die met sprints van één week werken, omschrijven het wekelijks plannen en de wekelijkse retro als „een last“, en zij hebben gelijk. 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 goed af te stemmen. 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 knop die u kunt aanpassen, geen gebod. (Dezelfde logica van overbelasting is van toepassing op elke ceremonie: zie anti-patronen bij stand-ups en de gebrek aan opvolging in onze veldgids „Agile Theatre”.)

Los het machtsprobleem op, waarborg de eerlijkheid, zorg dat één concreet punt daadwerkelijk wordt uitgevoerd en pas het tempo op de juiste manier aan; 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 nog een week lang standhoudt.

Veelgestelde vragen

Waarom verandert er eigenlijk nooit iets na onze retrospectives?

Meestal komt dit doordat de kwesties die het belangrijkst zijn 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 een beschrijving van de stand van zaken te hebben gegeven in plaats van deze 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 wanneer het werkelijke probleem buiten de invloedssfeer van het team ligt?

U escaleert het, en dat wordt officieel vastgelegd. Deel de kwesties in in zaken waarover het team de controle 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 retrospective die alleen problemen aan het licht brengt die het team al kan oplossen, is comfortabel maar 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 in een functioneringsgesprek weer naar voren komt als bewijs dat zij „te veel klagen“. Als de persoon die beslissingen neemt over promoties in de ruimte 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 ruimte 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 voltooide taak is, omdat de meeste sprints u geen kant-en-klaar resultaat opleveren. Herformuleer het doel. Een retrospectieve is geslaagd wanneer het team iets leert dat het mee kan nemen naar de volgende sprint, zelfs zonder een af te vinken taak, en wanneer er één eerlijk experiment wordt uitgevoerd in plaats van tien halfafgemaakte taken. Retrospectieven verrichten ook stiller werk (spanningen vroegtijdig aan het licht brengen, de samenhang binnen het team behouden) dat nooit als actiepunt naar voren komt, maar wel degelijk reëel is. Wanneer ze worden beschouwd als een leerritueel in plaats van als een takenfabriek, verdienen ze hun plaats.