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 retrospective 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 antipatronen bij retrospectives 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 retrospectives als tijdverspilling beschouwen: een macht-probleem en een opvolging-probleem. Geen enkele ijsbreker raakt aan deze kwesties. Als facilitering daadwerkelijk uw probleem is, ligt de oplossing in het houden van effectieve retrospectives, 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 het punt waarop onze eigen blogpost over anti-patronen de plank mis slaat. 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 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 geacht wordt een uitlaatklep voor klachten te zijn.”

Dat is de valkuil. De terugblik verandert in een drukventiel: 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 enkel „zeilboot-versus-zeester”-verhaal 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. 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 waarmee de kleinste verandering wordt gevonden 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 aangepakt. 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 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 gezegd wordt, binnen de groep blijft. Alleen de acties die het team besluit openbaar te maken, komen daarbuiten. 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 wanneer het voor een bepaald item nodig is.
• Wees voorzichtig met het introduceren van meetcijfers. Objectieve gegevens (velocity, cyclustijd) horen thuis in een retro, maar zodra velocity een streefcijfer 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 manier waarop het systeem faalt en 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 de hele discussie: „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 als een soort ‘Groundhog Day’ aanvoelen, van binnenuit ervaren worden. Het is geen verbeelding: het cijfer dat iedereen herhaalt – een veelgenoemd gegeven dat slechts ongeveer een derde van de teams hun actiepunten uit retrospectieven consequent afwerkt – blijkt de situatie somberder voor te stellen dan ze in werkelijkheid is. Wij hebben gemeten hoeveel actiepunten uit retrospectieven daadwerkelijk worden uitgevoerd aan de hand van honderdduizenden concrete 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 volkswijsheden wel gelijk in hebben, is de vorm die het falen aanneemt. Een actiepunt waar niemand verantwoordelijkheid voor neemt, zonder vastgestelde 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 doel. Dit is de nieuwe invalshoek uit de 2e editie van Agile Retrospectives waar de hele categorie naartoe evolueert. De belangrijkste verschuiving die Derby, Larsen en David Horowitz aanbrengen, 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 retrospectieve die geen afvinkbare actiepunten opleverde, maar het team daadwerkelijk iets heeft bijgebracht, is geen mislukte retrospectieve. Die ene stap neemt de klacht „er verandert niets“ weg, omdat het doel niet langer een voltooide taak is, maar een verandering die u daadwerkelijk doorvoert. Johanna Rothman paste deze vervanging al toe lang voordat deze 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 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 dat te interpreteren als een ongeïnteresseerd team. 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 willen benoemen. Werken op afstand maakt 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 kostenpost, geen excuus

Tot slot is er de kritiek die de voorstanders van „nooit de retro overslaan“ te snel terzijde schuiven: 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. Dat komt bovenop de Standups, de planning, de review en de verfijning. Bij korte sprints worden de cijfers genadeloos: teams met sprints van één week omschrijven wekelijkse planning en retro als „een last”, en zij hebben gelijk. Vijftig retro’s per jaar bij een ervaren team is geen deugd. Dezelfde klacht komt op organisatieniveau naar voren in het onderzoek naar de vergaderbelasting, waarbij het aandeel vergaderingen waarvan mensen zeggen dat ze die hadden kunnen overslaan, wordt gemeten in plaats van geschat.

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 verkeerd is, 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 geldt voor elke ceremonie: zie de anti-patronen bij Standups en het gebrek aan opvolging in onze veldgids ‘Agile Theatre’.)

Los het machtsprobleem op, waarborg de eerlijkheid, zorg dat één concreet punt daadwerkelijk wordt doorgevoerd 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 tool voor retrospectieven 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, 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 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 naam 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, officieel. 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 theater. 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 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. Herformuleer het doel. 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 eerlijk experiment wordt uitgevoerd in plaats van tien half afgemaakte taken. Retrospectieven verrichten ook stille 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 een takenfabriek, verdienen ze hun plaats.