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

Worden actiepunten uit de retrospectieve sessie 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 percentage het meest beïnvloedt, is de toewijzing: een actiepunt met een genoemde verantwoordelijke en een streefdatum wordt in ongeveer 90% van de gevallen voltooid.

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

Vraag waarom retrospectives mislukken en u krijgt ongetwijfeld een statistiek te horen, 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 de 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 zijn vastgesteld, werd uiteindelijk ~73% voltooid. Niet eens één op de drie. Eerder drie op de vier. De tijdsfactor is van belang, dus laten we dat meteen duidelijk maken: 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 staart.

Voordat u dit inlijst en aan de muur hangt: dit is een maximum, geen nationaal gemiddelde. Het gaat hier om teams die het belangrijk genoeg vinden om retrospectieven uit te voeren met behulp van een speciale tool; beschouw het dus als een voorbeeld van hoe het goed zou moeten zijn, niet als wat iedereen doet. Maar het maakt wel definitief een einde aan de gangbare mythe. „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 wel 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 de eigenaar ervan. 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 tijdens een retro, en negen van de tien acties verlaten de vergadering 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 voltooid“ interpreteert als „mislukt“, ziet er helemaal van af om zich nog aan grote acties te committeren.

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 afhankelijkheid tussen teams, 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. Wij hebben dit nog niet gemeten. Het is het patroon dat ten grondslag ligt aan veel van de ‘nooit-afgeronde’ kwartaaldoelen, en wij gaan hier uitgebreid op in in waarom retrospectieven mislukken.

Niemand heeft er nog eens naar gekeken. Dit is het belangrijkste punt, en de gegevens spreken voor zich. Teams die regelmatig een retrospectieve houden, ronden ongeveer drie op de vier van hun acties af; teams die slechts af en toe een retrospectieve houden, komen uit op ongeveer 55%. Het mechanisme is niet mysterieus: een regelmatige frequentie is wat de evaluatie afdwingt, 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, omdat het de goedkoopste en meest verwaarloosde optie is. Ongeveer één op de vier acties die nooit worden voltooid, bevindt 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 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: sommige teams doen er ongeveer twee keer zo lang over om datgene wat ze wel afmaken 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 beweging 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 theaterstukken zijn: retro’s zijn niet het probleem. Het zijn de onregelmatige retro’s die het probleem vormen.

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 uiterste datum zijn toegewezen, worden in ongeveer 90% van de gevallen voltooid. Taken waarvoor dit niet geldt, blijven in twee op de drie gevallen onvoltooid.

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 nu de bevinding die uw manier van oordelen over de opvolging zou moeten veranderen. Wanneer teams hun volgende retro binnenstappen, zijn de meeste actiepunten van de vorige retro nog niet afgehandeld, en dat jaagt mensen de paniek aan. 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 volgens de retro-tijdlijn te laat afgerond, niet omdat ze zijn opgegeven, maar omdat ze nog in behandeling waren toen de cyclus weer aan de beurt was. Dus “waarom is het actiepunt van de vorige retro nog niet afgerond?” is doorgaans 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 het deel van de gegevens dat aan niemand toebehoort, geen uiterste datum heeft en geen vast ritme kent. Alles hierboven beschrijft hoe u hieruit kunt komen.

Hoe zorgt u ervoor dat ze blijven hangen?

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

1. Stel één of twee actiepunten vast, niet tien. Hoe langer de lijst, hoe slechter de resultaten per punt: 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. Kies de verandering die het belangrijkst is en laat de rest los. 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 prioriteiten in te stellen, niet een lijst waaraan men zich moet committeren.
2. Vermeld op elk exemplaar de naam van een 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. Stel er een datum voor vast 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 vastgestelde verantwoordelijke en datum worden in ongeveer 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 waar het team iets van 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 uitsluitend 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 opneemt, zodat het afronden ervan zelf het werk is en niet 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 er iets nieuws aan de orde komt. Dit is de gewoonte die de rest in gang zet. 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 dit het eerste wat teams vaak achterwege laten. Lionel Luchez, manager software-engineering bij Snapsheet, beschrijft het in het artikel van BuiltIn over het actiever maken van retrospectieven 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 uit het afgelopen kwartaal daadwerkelijk zijn afgerond, en houd dat cijfer in de gaten in plaats van het aantal stickies dat het team heeft geproduceerd. Dit is de enige retrospectieve maatstaf die het waard is om naar boven toe te rapporteren, en het is degene die verbetert wanneer stap 1 tot en met 6 routine worden.

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

Begin met de basis: een gedeeld document met drie kolommen – ‘actie’, ‘verantwoordelijke’ en ‘deadline’ – dat aan het begin van elke retro wordt voorgelezen, is altijd beter dan welke tool dan ook die niemand opent. Als uw opvolging vandaag de dag te wensen overlaat, is het ontbrekende stukje vrijwel zeker de gewoonte om terug te blikken, 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 te gaan zoeken.
• De voltooiing wordt geregistreerd, zodat u uw voortgang over een kwartaal kunt zien in plaats van deze te moeten schatten.

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 door te voeren in Jira, Linear of een backlog, 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 deze acties – ongeveer 2 tot 3% van de steekproef – uit van 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 wordt vermeld, dus ook onze eigen gepubliceerde acties vallen 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 bestaan als iets ervoor zorgt dat deze opnieuw ter beoordeling wordt voorgelegd.

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 zijn opgesteld tijdens daadwerkelijke retrospectieven (type = actiondie expliciet zijn goedgekeurd, en geen AI-suggesties 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 daarvan, voldoende om statistisch robuust te zijn voor elk segment waarover wij rapporteren.
• “Voltooid” betekent dat een actie expliciet binnen het product als voltooid is gemarkeerd; dit wordt nooit afgeleid. Wij rapporteren de voltooiing „ooit” en op vaste tijdstippen (binnen drie maanden, tegen de volgende retro) afzonderlijk, omdat het verschil tussen beide cijfers het volledige verhaal weergeeft. Het cijfer van 73% in de kop is 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 onderschatten. Hetzelfde geldt voor de ~2–3% van de acties die in een externe tracker (meestal Jira) worden geregistreerd: zodra een actie in Jira staat, wordt de voltooiing ervan daar beheerd, niet in TeamRetro, dus meten wij alleen wat wij daadwerkelijk tot voltooiing kunnen zien komen. Beide uitsluitingen zijn conservatief.
• Wij rapporteren mediaanwaarden en verdelingen, en niet alleen gemiddelden, omdat de voltooiingstijden scheef verdeeld zijn en een gemiddelde ons in een gunstiger daglicht zou stellen.
• Eén ding waarnaar wij op zoek waren en dat wij niet hebben gevonden: een verband tussen de mate waarin een team zijn voornemens uitvoert en de scores van zijn eigen gezondheidscheck. Er is in feite geen enkel verband: het nakomen van voornemens is een kwestie van discipline, niet van stemming, en het ene laat zich niet afleiden uit het andere.

Wat wij niet zouden beweren

Vijf grenzen, duidelijk geformuleerd, want een getal zonder deze grenzen is het vermelden niet waard.

• Dit is een maximum, geen sectorgemiddelde. Teams die kiezen voor een speciale 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 in het ideale geval uitziet, niet als de norm die iedereen hanteert.
• Een deel van „uiteindelijk“ betreft administratieve verwerking. Een klein deel van de voltooide taken wordt in één keer afgesloten: 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 opschonen van een dashboard, en we kunnen niet altijd onderscheiden welk deel wat is. Als u elke late bulkafsluiting buiten beschouwing laat, ligt het minimumcijfer 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 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 als acties geregistreerd 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 zien komen. 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 wel 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 over meerdere teams heen, nooit om de gegevens van een individuele klant, nooit om iemands naam en nooit om de tekst van een actie. Segmenten worden alleen gerapporteerd boven een minimale drempelwaarde voor teams of acties. 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 voltooiingspercentage stijgt tot ~90% voor acties waaraan een specifieke verantwoordelijke en een uiterste datum zijn toegewezen, en teams die regelmatig een retrospective houden, voltooien ongeveer drie op de vier acties, 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 zeer 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 ook geen kwestie van opzet. Het is een kwestie van toewijzing en evaluatie, en beide onderdelen zijn vrij: sluit de retro af met een kleiner aantal actiepunten, die elk een naam 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 het uitvoeren van uw retrospectives in TeamRetro. Elke actie neemt de verantwoordelijke en de datum mee naar de volgende sessie, en de voltooiingsgraad is daar te zien.

Lees verder

• Waarom retrospectieven mislukken (en hoe u ervoor kunt zorgen dat die van u ertoe doen)
• De follow-through-leemte (Agile Theatre)
• Zijn retrospectieven de moeite waard? Een oordeel
• Hoe voert u een retrospectieve uit?
• Een checklist voor het houden van uw retrospectieve

Veelgestelde vragen

Worden de actiepunten uit de retrospectieve analyse daadwerkelijk afgehandeld?

Over het algemeen wel, en aanzienlijk vaker dan volgens de gangbare opvatting het geval zou zijn. Van de honderdduizenden actiepunten die in TeamRetro werden 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 uitgevoerd“ wordt overal aangehaald, maar nergens onderbouwd. Een ander voorbehoud bij ons cijfer: de steekproef bestaat uit teams die hun retrospectives in een speciale tool uitvoeren; beschouw 73% daarom als een indicatie van wat goed is, en niet als een sectoroverschrijdend gemiddelde.

Welk percentage van de retrospectief vastgestelde actiepunten wordt daadwerkelijk afgehandeld?

Volgens de eigen gegevens van TeamRetro, afkomstig uit een steekproef van honderdduizenden actiepunten die tijdens daadwerkelijke retrospectieven zijn opgesteld, waarbij demo- en interne accounts zijn verwijderd, wordt uiteindelijk ongeveer 73% voltooid. Dit percentage verschilt sterk per werkwijze: actiepunten 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 actiepunten, en bij teams die slechts af en toe een retrospective houden, daalt dit percentage tot ongeveer 55%. Ongeveer één op de vier actiepunten wordt 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 actie heeft geen aangewezen verantwoordelijke (slechts ongeveer 40% van de acties krijgt er een), er is geen streefdatum vastgesteld (slechts bij ongeveer 11% is dat het geval), de actie 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 uiterste datum 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 verantwoordelijke is niet per se degene die al het werk verricht; het is de persoon die verantwoordelijk is voor de voortgang van de actie en voor de verslaglegging 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 voordat de vergadering eindigt 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 zaken waartoe het team zich al heeft verbonden, 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 procent. De reden voor dit verschil is simpelweg of er iets is dat de evaluatie afdwingt. Wanneer iets niet is voltooid, is de relevante vraag of er nog vooruitgang wordt geboekt, niet wie de schuldige is.

Hoe houdt u actiepunten bij die tijdens een retrospectieve sessie zijn vastgesteld?

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 veel beter dan een tool die niemand opent. Een speciale tool voor retrospectives helpt door de drie knelpunten weg te nemen waar die gewoonte vaak mislukt: de tool registreert de verantwoordelijke en de deadline terwijl het team nog in de vergaderruimte is, brengt openstaande acties tijdens de volgende sessie opnieuw ter sprake 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 doorlezen, zelfs nadat de actie in uw tracker is opgenomen. Een opmerking over de cijfers op deze pagina: acties die naar een externe tracker worden gepubliceerd, zijn 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. TeamRetro, waar deze gegevens vandaan komen, stelt u in staat om tijdens de vergadering zelf aan elke actie een verantwoordelijke en een streefdatum toe te wijzen, zorgt ervoor dat openstaande acties zichtbaar blijven bij de volgende retrospectieve zodat ze worden geëvalueerd voordat er iets nieuws wordt toegevoegd, en registreert de voltooiing, 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, waarover het team zeggenschap heeft, waarop het invloed kan uitoefenen en waarmee het zich moet schikken; 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, met vermelding van de uiterste termijn. 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, omdat teams met een vast ritme veel vaker hun doelen bereiken 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.