De Follow-Through-index: worden retroactive actiepunten daadwerkelijk afgehandeld?

Worden actiepunten uit de retrospectieve periode daadwerkelijk afgehandeld? Meestal wel. Van de honderdduizenden actiepunten die in TeamRetro worden bijgehouden, werd uiteindelijk ongeveer 73% voltooid, en niet die „één op de drie“ die overal wordt aangehaald. Ongeveer de helft wordt binnen drie maanden afgehandeld, en ongeveer een kwart vóór de volgende retro van het team. De factor die dit cijfer het meest beïnvloedt, is de toewijzing: een actiepunt met een benoemde verantwoordelijke en een deadline wordt in ongeveer 90% van de gevallen voltooid.

Dit cijfer is afkomstig van teams die hun retrospectieven met behulp van een speciale tool houden; beschouw het daarom eerder als een voorbeeld van hoe het er in het ideale geval uitziet dan als een branchegemiddelde. Op de rest van deze pagina wordt de werkwijze toegelicht.

Vraag waarom retrospectives mislukken en iemand zal u een statistiek voor de voeten werpen, een variant op „slechts ongeveer een derde van de actiepunten uit retrospectives wordt ooit uitgevoerd.” U hoort het overal. Er wordt nergens een bron voor genoemd. Niemand weet het exacte cijfer.

Dat doen wij inderdaad. TeamRetro organiseert voldoende retrospectieven om dat ene aspect te meten dat bepaalt of het uur de moeite waard was: voeren teams daadwerkelijk uit wat ze hebben besloten? Onze steekproef bestaat uit honderdduizenden daadwerkelijke actiepunten, geen enquête en geen gok.

Het is geen derde. Het is bijna driekwart.

De kop: ongeveer 73% van de retro-acties wordt daadwerkelijk uitgevoerd

Van een steekproef van honderdduizenden actiepunten die tijdens daadwerkelijke retrospectives werden vastgelegd, werd uiteindelijk ~73% voltooid. Niet één op de drie. Eerder drie op de vier. De tijdsfactor is van belang, dus laten we dat meteen duidelijk stellen: ongeveer de helft van de actiepunten wordt binnen drie maanden na het opstellen ervan afgehandeld, ongeveer een kwart vóór de volgende retrospectieve van het team, en de rest van de uiteindelijk voltooide actiepunten volgt in een langgerekte curve.

Voordat u dit inlijst en aan de muur hangt: dit is een maximum, geen nationaal gemiddelde. Dit zijn teams die er voldoende waarde aan hechten om retrospectieven uit te voeren met behulp van een speciale tool; beschouw het dus als een voorbeeld van hoe goed eruitziet, niet als wat iedereen doet. Maar het maakt wel definitief een einde aan de gangbare misvatting. „Ongeveer een derde“ is nergens waar we kunnen zien de waarheid over retrospectieven: zelfs de teams die helemaal geen vast ritme voor retrospectieven hebben, voltooien er ongeveer 55 %. De mythe heeft de richting goed, maar de omvang verkeerd, en de kloof waarnaar het verwijst – ritme en eigenaarschap – is precies waar de rest van de gegevens over gaat.

Waarom actiepunten niet worden uitgevoerd

Het meeste advies over deze kwestie bestaat uit een opsomming van beweringen. Hieronder volgen de storingspatronen die wij daadwerkelijk in de gegevens kunnen waarnemen, en één patroon dat wij niet kunnen waarnemen, dat als zodanig is gemarkeerd.

Niemand is er eigenaar van. Slechts ongeveer 40% van de acties krijgt überhaupt een eigenaar. Acties met een eigenaar en een datum worden in ongeveer 90% van de gevallen voltooid; bij acties zonder eigenaar en zonder datum ligt dit percentage aanzienlijk lager, namelijk op ongeveer 67%. Dit is het grootste meetbare verschil op de pagina en het kan kosteloos worden weggewerkt.

Er is geen datum. Slechts ongeveer 11% van de acties krijgt ooit een uiterste datum. Een datum is het goedkoopste middel om toezeggingen vast te leggen dat tijdens een retro beschikbaar is, en negen van de tien acties verlaten de vergaderruimte zonder een dergelijke datum.

Het was te omvangrijk voor één cyclus. Het duurt gemiddeld ongeveer zes weken om een actie af te ronden, en de meeste teams voeren vaker dan dat een retro uit. Een actie ter grootte van een kwart lijkt bij de volgende vergadering al opgegeven, ook al is er nog vooruitgang, en een team dat „niet afgerond“ interpreteert als „mislukt“, durft zich helemaal niet meer aan grote acties te wijden.

Het was nooit aan het team om dit op te lossen. Sommige acties zijn in feite een verzoek dat aan iemand anders is gericht: personeelsbezetting, een teamoverschrijdende afhankelijkheid, een implementatiepijplijn waarvoor niemand in de vergaderruimte verantwoordelijk is. Als het als een teamactie wordt geregistreerd, blijft het daar liggen. Als het als escalatie wordt aangekaart, met een naam en een datum erbij, komt er schot in de zaak. Dit hebben wij nog niet gemeten. Het is het patroon dat ten grondslag ligt aan een groot deel van de ‘nooit voltooide’ kwartaaldoelen, en wij gaan hier uitgebreid op in bij de vraag waarom retrospectives mislukken.

Niemand heeft er nog eens naar gekeken. Dit is het belangrijkste punt, en de gegevens spreken boekdelen. Teams die regelmatig een retrospectieve houden, voltooien ongeveer driekwart van hun acties; teams die slechts af en toe een retrospectieve houden, komen uit op ongeveer 55%. Het mechanisme is niet mysterieus: een regelmatige frequentie dwingt tot evaluatie, en zonder evaluatie wordt er niets afgerond. De oplossing is een gewoonte, geen software.

Dat laatste is het waard om even bij stil te staan, want het is de goedkoopste en meest verwaarloosde optie. Ongeveer één op de vier acties die nooit worden afgerond, bevinden zich overwegend in de hoek waar deze mislukkingen zich opstapelen: geen verantwoordelijke, geen datum, geen ritme.

Factor 1: cadans. Teams met een ritme halen de finish; teams zonder ritme doen dat niet.

Het grootste verschil in de gegevens betreft de frequentie waarmee een team een retrospective houdt.

• Teams die op regelmatige basis een retro houden, voltooien ongeveer drie op de vier van hun acties.
• Teams die slechts af en toe een retro houden (met lange tussenpozen tussen de sessies, of slechts een handvol retro’s in totaal) komen uit op ongeveer 55%.

Dezelfde tool, dezelfde functies, tegengestelde resultaten. En het gaat niet alleen om de voltooiing: bij sommige teams duurt het ongeveer twee keer zo lang om de taken die zij wel afronden af te ronden (bijna drie maanden, tegenover ongeveer zes weken voor teams die een vast ritme hebben). Een retro is geen vergadering; het is een cyclus. Teams die de cyclus in gang houden, sluiten de cyclus af. Teams die dat niet doen, doen dat niet.

Dit is het ongemakkelijke punt voor degenen die vinden dat retro’s theater zijn: retro’s zijn niet het probleem. Onregelmatige retro’s zijn dat wel.

Punt 2: verantwoordelijkheid. Een actie zonder verantwoordelijke is slechts een wens.

Hier volgt de bevinding waarop u vanmiddag actie kunt ondernemen. Taken waaraan een specifieke verantwoordelijke en een deadline zijn toegewezen, worden in ongeveer 90% van de gevallen voltooid. Taken waarbij dat beide ontbreekt, blijven in twee op de drie gevallen liggen.

En toch maken teams er nauwelijks gebruik van. Slechts ongeveer 40% van de acties krijgt überhaupt een verantwoordelijke toegewezen, en slechts ~11% krijgt ooit een streefdatum. Dat is de kloof: niet de inspanning, niet de intentie, maar de toewijzing. De meeste teams verlaten de retro met een lijst vol goede voornemens waarop geen namen staan, en vragen zich vervolgens af waarom die lijst twee weken later nog steeds bestaat.

Het advies spreekt dus voor zich, en het is precies het tegenovergestelde van waar de meeste facilitators zich op richten. Ga niet weg met de langste lijst van dingen die u zou kunnen doen. Ga weg met twee punten die elk een naam en een datum hebben. Een actie zonder verantwoordelijke is geen actie; het is een wens die het hele team stilletjes heeft afgesproken te negeren.

De mytheontkrachting: retrospectieven lopen hun eigen daden vooruit

Hier volgt de bevinding die uw manier van beoordelen van de opvolging zou moeten veranderen. Wanneer teams aan hun volgende retro beginnen, zijn de meeste acties uit de vorige retro nog niet afgerond, en dat brengt mensen in paniek. Dat zou echter niet het geval moeten zijn.

Het duurt ongeveer zes weken (mediaan) om acties af te ronden, en de meeste teams voeren hun evaluaties sneller uit dan dat. De werkelijke gang van zaken bij de opvolging ziet er dus grofweg als volgt uit:

• ~1 op de 4 handelingen die tijdens de volgende retro worden uitgevoerd,
• ~1 op de 2 is voltooid, maar nadat de volgende retro al heeft plaatsgevonden,
• ~1 op de 4 heeft dit nog nooit gedaan.

De helft van alle actiepunten die teams opstellen, wordt te laat afgerond volgens de retro-tijdschema, niet omdat ze zijn opgegeven, maar omdat ze nog in behandeling waren toen de cyclus weer begon. Dus “waarom is het actiepunt van de vorige retro nog niet afgerond?” is meestal de verkeerde vraag. De vraag die u moet stellen, is of er vooruitgang wordt geboekt. Beoordeel de opvolging op basis van een kwartaalritme, niet op basis van een periode van twee weken.

De laatste regel van die lijst vormt de echte leemte: ongeveer één op de vier acties wordt nooit voltooid, en deze bevinden zich overwegend in dat gedeelte van de gegevens dat aan niemand toebehoort, geen uiterste datum heeft en geen vast ritme kent. Alles wat hierboven staat, laat zien hoe u hieruit kunt komen.

Hoe zorgt u ervoor dat ze blijven plakken?

Zeven stappen, in volgorde. Geen enkele daarvan betreft software.

1. Sluit af met één of twee actiepunten, niet met tien. Hoe langer de lijst, hoe minder effectief elk punt op die lijst is: bij retrospectieven die met tien of meer actiepunten worden afgesloten, wordt ongeveer 56% daarvan voltooid, tegenover ongeveer 79% bij retrospectieven die met één tot drie actiepunten worden afgesloten. Kies de verandering die het meest van belang is en laat de rest los. Als het team daadwerkelijk tien problemen aan het licht heeft gebracht die het waard zijn om op te lossen, dan is dat een lijst om prioriteiten in te stellen, niet een lijst waaraan men zich moet houden.
2. Vermeld op elk exemplaar de naam van één persoon. Geen team, geen functie, en ook niet standaard de Scrum Master. Eén persoon die hardop „ja” heeft gezegd. De eigenaar is niet degene die al het werk verricht. Het is de persoon die verantwoordelijk is voor de voortgang ervan en die aangeeft wat de volgende stap is.
3. Zet er een datum op voordat de vergadering ten einde loopt. Niet „volgende sprint“, maar een concrete datum. Dit is de stap die teams vaak overslaan: slechts ongeveer één op de negen acties krijgt er ooit een, en acties met een toegewezen verantwoordelijke en een datum worden in ~90% van de gevallen voltooid.
4. Pas de omvang aan zodat deze binnen één cyclus past. Als de actie redelijkerwijs niet vóór de volgende retro kan worden afgerond, is het nog geen actie. Splits deze op in een eerste deel dat wel haalbaar is, of herformuleer het als een experiment: een hypothese, een evaluatiedatum en een eerlijke analyse van wat er is gebeurd. Een experiment waaruit het team iets heeft geleerd, is een succes, zelfs zonder dat er een vinkje in een vakje staat, terwijl een actiepunt dat stilletjes zes sprints lang wordt doorgeschoven, juist de tegenovergestelde les leert.

5. Neem het op in het volgende werkblok. Een actie die alleen op het retro-bord staat, concurreert met de sprint in plaats van er deel van uit te maken. Plaats het daar waar het team daadwerkelijk werk uit haalt, zodat het afronden ervan juist het werk zelf is, in plaats van iets extra’s ernaast. Onze eigen timinggegevens pleiten het sterkst voor deze stap: het duurt gemiddeld ongeveer zes weken om een actie af te ronden, terwijl het team gemiddeld om de twee weken een retro houdt. Johanna Rothman beveelt deze aanpak al jaren aan in Create Your Successful Agile Project: één item, behandeld als een experiment, waarbij het volgende werkblok zo wordt opgezet dat het dit item omvat.
6. Begin de volgende retro met de actiepunten van de vorige keer, voordat u aan iets nieuws begint. Dit is de gewoonte die de rest in de hand houdt. Lees ze voor, geef aan wat er is gedaan en vraag bij alles wat nog niet is afgerond of er nog vooruitgang wordt geboekt, in plaats van te vragen wie de schuldige is. Dit zijn de vijf minuten met de grootste toegevoegde waarde tijdens de vergadering, en toch is het het eerste wat teams achterwege laten. Lionel Luchez, manager software-engineering bij Snapsheet, beschrijft dit in het artikel van BuiltIn over het actiever maken van retrospectives als de gehele eerste fase van hun retrospective: „Fase één bestaat uit het evalueren van de opgeloste knelpunten sinds de vorige vergadering.” Er komt niets nieuws op het bord totdat dat is afgerond.
7. Houd uw voltooiingspercentage bij, niet het aantal acties. Tel hoeveel acties van het afgelopen kwartaal daadwerkelijk zijn afgerond, en houd dat aantal in de gaten in plaats van het aantal sticky notes dat het team heeft geproduceerd. Dit is de enige retro-statistiek die het waard is om aan het management te rapporteren, en het is degene die verbetert wanneer stap 1 tot en met 6 routine worden.

Hoe u ze kunt bijhouden, en wanneer u geen hulpmiddel nodig hebt

Begin met de basis: een gedeeld document met drie kolommen – ‘actie’, ‘verantwoordelijke’ en ‘uiterste datum’ – dat aan het begin van elke retro wordt voorgelezen, is beter dan welke tool dan ook die niemand opent. Als uw opvolging vandaag de dag niet goed verloopt, is het ontbrekende stukje vrijwel zeker de gewoonte om te evalueren, en niet de software. Breng die gewoonte op orde met wat u al tot uw beschikking heeft, en u zult het grootste deel van de voordelen van deze gegevens kosteloos benutten.

Een hulpmiddel bewijst zijn nut door de drie momenten weg te nemen waarop die gewoonte wordt doorbroken:

• De afspraak wordt met vermelding van de verantwoordelijke en de datum tijdens de vergadering zelf vastgelegd, terwijl het team nog in de vergaderruimte aanwezig is om hiermee in te stemmen, in plaats van dat deze achteraf wordt opgeschreven door degene die notulen heeft gemaakt.
• Openstaande acties van de vorige keer verschijnen aan het begin van de volgende sessie, voordat iemand iets nieuws toevoegt. Niemand hoeft eraan te denken om ernaar op zoek te gaan.
• De voltooiing wordt geregistreerd, zodat u uw voortgang over een kwartaal kunt zien in plaats van ernaar te moeten gissen.

Dat is wat het retrospectieve bijhouden van acties in TeamRetro doet, en daar zijn de gegevens op deze pagina afkomstig van.

Het is prima om acties in Jira, Linear of een backlog op te nemen, met één voorbehoud waarover wij heel duidelijk willen zijn. Zodra een actie in uw tracker staat, wordt de voltooiing ervan daar beheerd. Daarom sluiten wij die acties – ongeveer 2 tot 3% van de steekproef – uit deze gegevens: wij kunnen niet controleren of ze worden voltooid, dus tellen wij ze niet mee. Ons eigen team werkt op deze manier, zoals in de zijbalk hierboven staat vermeld, dus onze eigen gepubliceerde acties vallen ook onder dat uitgesloten deel. Dat is een beperking van onze meting, geen bewijs dat die acties mislukken. Het praktische risico is hetzelfde als bij een gedeeld document: een actie die uit de aandacht van de retro verdwijnt, blijft alleen in beeld als er iets is dat deze ter beoordeling terugbrengt.

Hoe wij dit hebben gemeten

Geen enquête, geen zelfrapportage over zelfrapportage. Dit zijn gebeurtenissen die in het product zijn vastgelegd:

• Steekproef: een omvangrijke steekproef van actiepunten die tijdens daadwerkelijke retrospectieven zijn opgesteld (type = actiondie expliciet zijn goedgekeurd, en geen AI-voorstellen die door een facilitator zijn afgewezen) binnen teams die gebruikmaken van TeamRetro, waarbij demo-, interne en testaccounts zijn verwijderd en accounts die tussen onze hostingregio’s zijn gemigreerd slechts één keer zijn meegeteld. Honderdduizenden stuks, voldoende om statistisch robuust te zijn voor elk segment waarover wij rapporteren.
• “Voltooid” betekent dat een actie expliciet in het product als voltooid is gemarkeerd; dit wordt nooit afgeleid. Wij rapporteren „ooit“ voltooid en voltooid binnen vaste termijnen (binnen drie maanden, tegen de volgende retro) afzonderlijk, omdat het verschil tussen beide het volledige beeld weergeeft. Het percentage van 73% in de kop verwijst naar het „ooit“-cijfer.
• Wat wij hebben weggelaten, en waarom. Afspraken zijn bewust buiten beschouwing gelaten: de vaste werkafspraken van een team („oneens zijn en toch uitvoeren”, „camera’s aan tijdens demo’s”) zijn doorlopende normen, geen taken die u kunt afvinken, en het tellen ervan zou de mate van naleving te laag weergeven. Hetzelfde geldt voor de ~2–3% van de acties die in een externe tracker (meestal Jira) worden vastgelegd: zodra een actie in Jira staat, wordt de voltooiing ervan daar beheerd, niet in TeamRetro, dus meten wij alleen wat wij daadwerkelijk kunnen zien worden afgerond. Beide uitsluitingen zijn conservatief.
• Wij rapporteren mediaanwaarden en verdelingen, niet alleen gemiddelden, omdat de voltooiingstijden scheef verdeeld zijn en een gemiddelde ons in een te gunstig daglicht zou stellen.
• Eén ding waarnaar wij op zoek waren en dat wij niet hebben gevonden: enig verband tussen de mate waarin een team zijn afspraken nakomt en de scores op de eigen gezondheidscheck. Er is in feite geen enkel verband: het nakomen van afspraken is een kwestie van discipline, niet van stemming, en het ene kan niet uit het andere worden afgeleid.

Wat wij niet zouden beweren

Vijf beperkingen, duidelijk uiteengezet, want een getal zonder deze beperkingen is het vermelden niet waard.

• Dit is een maximum, geen sectorgemiddelde. Teams die kiezen voor een gespecialiseerde retro-tool, zetten dit vrijwel zeker ook daadwerkelijk door, in tegenstelling tot teams die dat niet doen. Beschouw ~73% als een voorbeeld van hoe het er goed uitziet, niet als wat iedereen doet.
• Een deel van dat „uiteindelijk” betreft administratieve verwerking. Een klein deel van de voltooide taken wordt in één keer afgerond: tien of meer acties die in dezelfde minuut als voltooid worden gemarkeerd, vaak zes maanden of langer nadat ze zijn aangemaakt. Een deel daarvan betreft daadwerkelijk werk dat wordt afgestemd met een externe tracker; een ander deel betreft het opruimen van een bord, en wij kunnen niet altijd onderscheiden wat wat is. Als u elke late bulkafsluiting buiten beschouwing laat, komt het minimumcijfer uit op ongeveer 69 %. Beschouw dit als „ongeveer zeven op de tien, mits er voldoende tijd is”, en u bevindt zich hoe dan ook binnen de foutmarges.
• “Als voltooid gemarkeerd” is niet hetzelfde als “een verschil hebben gemaakt”. Voltooiing vormt de basis voor de impact, maar is geen bewijs daarvan. Wij kunnen zien dat de actie is afgerond. Wij kunnen echter niet zien of deze effect heeft gehad.
• Sommige daadwerkelijke afspraken worden ten onrechte geregistreerd als acties en worden nooit voltooid, waardoor het gemeten percentage omlaag gaat. Voor echte taken ligt het werkelijke aantal dus, als er al een verschil is, zelfs iets hoger.
• Wij meten alleen wat wij tot een goed einde kunnen brengen. Acties die naar een externe tracker worden verzonden, worden buiten beschouwing gelaten, evenals lopende werkafspraken. Beide uitsluitingen zijn bewust gekozen en beide zijn conservatief.

En wat wij niet over ons eigen product zullen beweren: TeamRetro biedt geen garantie dat men het volhoudt, en dat geldt ook voor alle andere producten. Het maakt het gemakkelijker om de gewoonte vol te houden. Dat is een bescheiden bewering, en het is een waarheid.

Privacy

Alle cijfers hier zijn geaggregeerd en geanonimiseerd: het gaat om het aantal gebeurtenissen verspreid over vele teams, nooit om de gegevens van één enkele klant, nooit om de naam van iemand, nooit om de tekst van een actie. Segmenten worden alleen gerapporteerd boven een minimale drempelwaarde per team of actie. De volledige veiligheidsmaatregelen zijn vastgelegd in de interne specificatie.

Verwijs hiernaar

Van een steekproef van honderdduizenden retrospectieve actiepunten die in TeamRetro werden bijgehouden, werd ongeveer 73% uiteindelijk voltooid – ruwweg drie op de vier – en niet de in de volksmond genoemde „één op de drie”: ongeveer de helft binnen drie maanden, ongeveer een kwart vóór de volgende retro van het team. Het percentage voltooide actiepunten stijgt tot ~90% wanneer er een specifieke verantwoordelijke en een deadline aan een actiepunt is toegewezen, en teams die regelmatig een retrospective houden, voltooien ongeveer drie op de vier actiepunten, tegenover ongeveer 55% voor teams die slechts af en toe een retrospective houden. — The Follow-Through Index, TeamRetro (2026)

Wilt u dit gebruiken in een onderzoek of een lezing? Wij zouden het op prijs stellen als u een link naar ons zou plaatsen.

Wat dit voor u betekent

Het nakomen van afspraken is geen kwestie van discipline en evenmin een kwestie van opzet. Het is een kwestie van toewijzing en evaluatie, en beide onderdelen zijn eenvoudig: sluit de retro af met een kleiner aantal actiepunten, die elk een verantwoordelijke en een datum hebben, en begin de volgende sessie door deze voor te lezen. Als u liever hebt dat dit gebeurt zonder dat iemand eraan hoeft te denken om het te regelen, dan is dat precies de taak van de functie voor het uitvoeren van uw retrospectives in TeamRetro. Elke actie neemt de verantwoordelijke en de datum mee naar de volgende sessie, en u kunt de voltooiingsgraad daar bekijken.

Lees verder

• Waarom retrospectieven mislukken (en hoe u ervoor kunt zorgen dat die van u echt iets opleveren)
• De leemte in de afwerking (Agile Theatre)
• Zijn retrospectieven de moeite waard? Een oordeel
• Hoe voert u een retrospectieve uit?
• Een checklist voor het houden van uw retrospectieve
• Statistieken over agile en retrospectieven: het externe onderzoek naar retrospectieven, waarbij elk cijfer is gekoppeld aan de studie waaruit het afkomstig is.

Veelgestelde vragen

Worden actiepunten uit retrospectieven daadwerkelijk afgehandeld?

Over het algemeen wel, en aanzienlijk vaker dan in de gangbare opvatting wordt aangenomen. Van de honderdduizenden actiepunten die in TeamRetro zijn bijgehouden, werd uiteindelijk ongeveer 73% voltooid, oftewel ruwweg drie op de vier. ‘Uiteindelijk’ is hier de juiste term: ongeveer de helft van de acties wordt binnen drie maanden na het opstellen ervan uitgevoerd, en ongeveer een kwart vóór de volgende retro van het team. De veelgehoorde bewering dat „slechts ongeveer een derde wordt voltooid” wordt overal aangehaald, maar nergens onderbouwd. Een andere kanttekening bij ons cijfer: de steekproef bestaat uit teams die hun retrospectives in een speciale tool uitvoeren; beschouw 73% daarom als een indicatie van wat als goed wordt beschouwd, en niet als een brancheoverschrijdend gemiddelde.

Welk percentage van de retrospectieve actiepunten wordt daadwerkelijk afgehandeld?

Volgens de eigen gegevens van TeamRetro, afkomstig uit een steekproef van honderdduizenden actiepunten die tijdens daadwerkelijke retrospectieven zijn vastgelegd, waarbij demo- en interne accounts zijn uitgesloten, wordt uiteindelijk ongeveer 73% voltooid. Dit percentage verschilt sterk per werkwijze: acties met een genoemde verantwoordelijke en een uiterste datum worden in ongeveer 90% van de gevallen voltooid; teams die regelmatig retrospectieven houden, voltooien ongeveer drie op de vier acties, en bij teams die slechts af en toe een retrospectief houden, daalt dit percentage tot ongeveer 55%. Ongeveer een op de vier acties wordt helemaal nooit voltooid.

Waarom worden onze actiepunten uit de retrospectieve eigenlijk nooit afgerond?

Meestal is er sprake van één van de vijf redenen, en alleen de eerste twee hebben betrekking op de inspanning: de taak heeft geen aangewezen verantwoordelijke (slechts ongeveer 40% van de taken krijgt er een), er is geen deadline (slechts ongeveer 11% heeft er een), de taak was te omvangrijk om binnen één cyclus af te ronden, het was überhaupt nooit de taak van het team om dit op te lossen, of, wat het vaakst voorkomt, niemand heeft er nog eens naar gekeken. Uit de gegevens blijkt duidelijk wat het belangrijkst is: teams die regelmatig een retrospective houden, voltooien ongeveer drie op de vier van hun acties, terwijl teams die slechts af en toe een retrospective houden, slechts ongeveer 55% voltooien. De oplossing die het verschil maakt, is een gewoonte om acties te evalueren, niet een nieuwe tool.

Waarom lijken de actiepunten uit onze vorige retro nooit afgerond te zijn tegen de tijd dat de volgende plaatsvindt?

Omdat retrospectieven hun eigen acties vooruitlopen. Het duurt gemiddeld ongeveer zes weken om een actie af te ronden, en de meeste teams houden vaker dan dat een retrospective, waardoor ongeveer de helft van alle acties pas is afgerond nadat de volgende retrospective al heeft plaatsgevonden. „Nog niet af“ betekent meestal „nog in uitvoering“, niet „mislukt“. Maak u zorgen over de actie die niet vordert, niet over degene die bij de volgende vergadering nog niet is afgerond.

Hoeveel actiepunten zou een retrospectieve moeten opleveren?

Eén of twee, elk met een verantwoordelijke en een deadline, en elk opgenomen in de volgende werkfase in plaats van op een bord achtergelaten te worden. Lange lijsten leveren aantoonbaar slechtere resultaten op: bij retrospectieven die eindigen met tien of meer actiepunten wordt ongeveer 56% daarvan voltooid, tegenover ongeveer 79% bij retrospectieven die eindigen met één tot drie actiepunten. Een verantwoordelijke en een streefdatum verhogen de voltooiingsgraad tot ongeveer 90%, dus twee acties met een verantwoordelijke presteren altijd beter dan tien acties zonder verantwoordelijke. Als het team daadwerkelijk tien problemen aan het licht heeft gebracht die het waard zijn om opgelost te worden, dan is dat een lijst om de komende maanden prioriteit aan te geven, niet een lijst om in deze sprint af te werken.

Wie dient verantwoordelijk te zijn voor een actiepunt uit de retrospectieve?

Eén met naam genoemde persoon die hiermee tijdens de vergadering heeft ingestemd – niet het team, niet een functie en niet standaard de Scrum Master. De eigenaar is niet noodzakelijkerwijs degene die al het werk verricht; het is de persoon die verantwoordelijk is voor de voortgang van de actie en voor het rapporteren hierover tijdens de volgende retro. Slechts ongeveer 40% van de acties uit de retrospectieve krijgt überhaupt een verantwoordelijke toegewezen, en acties met een verantwoordelijke en een datum worden in ongeveer 90% van de gevallen voltooid. Dit maakt het hardop benoemen van iemand vóór het einde van de vergadering de goedkoopste verbetering die voor elk team beschikbaar is.

Moet u aan het begin van een retrospectieve oude actiepunten doornemen?

Ja, voordat er iets nieuws op het bord wordt gezet. Dit zijn de vijf minuten met de grootste waarde tijdens de vergadering: hiermee wordt de cirkel gesloten rond de toezeggingen die het team al heeft gedaan, en komen de acties aan het licht die niet vorderen, terwijl er nog tijd is om er iets aan te doen. Onze gegevens laten zien waarom dit van belang is: teams met een regelmatig retro-ritme voltooien ongeveer drie op de vier van hun acties, terwijl teams die slechts af en toe een retro houden terugvallen tot ongeveer 55%. Het mechanisme achter dat verschil is simpelweg de vraag of er iets is dat de evaluatie afdwingt. Wanneer iets niet is voltooid, is de nuttige vraag of er nog vooruitgang wordt geboekt, niet wie de schuldige is.

Hoe houdt u retrospective actiepunten bij?

Leg elke actie tijdens de vergadering zelf vast, met een verantwoordelijke en een uiterste datum; bewaar de nog openstaande acties op een plek waar het hele team ze kan zien, en lees ze aan het begin van de volgende retro voor. Een gedeeld document met drie kolommen – actie, verantwoordelijke en uiterste datum – dat bij elke sessie wordt doorgenomen, werkt prima en is beter dan welke tool dan ook die niemand opent. Een speciale tool voor retrospectives helpt door de drie knelpunten weg te nemen waar die gewoonte vaak misgaat: de tool registreert de verantwoordelijke en de deadline terwijl het team nog in de vergaderruimte is, brengt openstaande acties tijdens de volgende sessie opnieuw onder de aandacht voordat er iets nieuws wordt toegevoegd, en registreert de voltooiing, zodat u uw voortgang kunt zien in plaats van ernaar te moeten gissen.

Moet u retrospectieve acties in Jira of Linear vastleggen?

Dat kan, en veel teams doen dat ook, waaronder het onze: ons eigen Customer Success-team publiceert de actiepunten van elke retro in Linear zodra voor elk punt een verantwoordelijke is aangewezen. Wat bepaalt of dit werkt, is niet in welke tool de actie is vastgelegd, maar of deze ter beoordeling opnieuw onder de aandacht wordt gebracht; blijf de openstaande lijst daarom aan het begin van de volgende retro doornemen, zelfs nadat deze in uw tracker is opgenomen. Een opmerking over de cijfers op deze pagina: acties die naar een externe tracker worden gepubliceerd, worden uitgesloten van onze dataset – ongeveer 2 tot 3% van de steekproef – omdat de voltooiing ervan daar wordt geregistreerd en wij alleen tellen wat wij kunnen zien worden afgerond.

Zijn er hulpmiddelen die helpen om actiepunten uit de retrospectieve evaluatie af te ronden?

Ja, een speciale tool voor retrospectieven maakt de cirkel rond die een takenlijst openlaat. Met TeamRetro, waar deze gegevens vandaan komen, kunt u tijdens de vergadering zelf aan elke actie een verantwoordelijke en een uiterste datum toewijzen, blijven openstaande acties zichtbaar tijdens de volgende retrospective zodat ze worden geëvalueerd voordat er iets nieuws wordt toegevoegd, en wordt de voltooiing geregistreerd zodat u kunt zien hoe uw voltooiingspercentage verbetert. Welke tool u ook gebruikt, dit zijn de mechanismen die het resultaat beïnvloeden: verantwoordelijkheid, zichtbaarheid bij de volgende retro en een gemeten voltooiingspercentage. En mocht de gewoonte om te evalueren er nog niet zijn, dan is een gedeeld document dat bij elke retro wordt voorgelezen nog altijd beter dan een tool die niemand opent.

Hoe gaat u om met gebeurtenissen waar het team geen invloed op heeft?

Escaleer ze met vermelding van de naam in plaats van ze opnieuw op te sommen. Sorteer elk probleem op basis van wie er daadwerkelijk verantwoordelijk voor is, waar het team controle over heeft, waarop het invloed kan uitoefenen en waarmee het zich slechts moet verzoenen; zet vervolgens de punten uit de buitenste ring om in een zichtbaar verzoek waarin de belemmering wordt benoemd, de kosten worden gekwantificeerd en de persoon wordt genoemd die actie moet ondernemen, evenals de uiterste termijn daarvoor. Een actie die het team nooit heeft kunnen voltooien, is geen tekortkoming in de opvolging; het is een punt dat op de verkeerde plaats is ondergebracht. Houd één door het team beheerde verbetering over waar het team aan kan werken, en stuur de rest officieel door naar een hoger niveau.

Hoe zorgt u ervoor dat er daadwerkelijk retrospective acties plaatsvinden?

Twee punten, in volgorde. Regelmatige retrospectieven, want teams met een vast ritme ronden veel meer af dan teams die slechts af en toe een retrospectief houden. En wijs aan elke actie een verantwoordelijke en een uiterste datum toe, want acties met een verantwoordelijke en een uiterste datum worden in ongeveer 90% van de gevallen voltooid, terwijl slechts ongeveer een tiende van de acties überhaupt een uiterste datum krijgt. Het is beter om met twee acties met een verantwoordelijke te vertrekken dan met tien acties zonder verantwoordelijke.