Download de template voor een retrospective
Print hem voor aan de muur of bewerk hem in de tool die je al gebruikt. Gratis, zonder e-mailadres en zonder aanmelding. De bestanden zijn in het Engels.
Een agile retrospective is een korte, terugkerende bijeenkomst waarin een team terugkijkt op een periode van werk, meestal een sprint, en afspreekt wat het verandert aan hoe het werkt. Een planningsoverleg gaat over wat het team gaat bouwen; een retrospective gaat over de manier waarop het bouwt. Wat eruit komt is geen lijst met klachten, maar een of twee concrete veranderingen die het team uitprobeert vóór de volgende retrospective.
Retrospectives komen rechtstreeks uit het Agile Manifesto van 2001. Het laatste principe daarvan vraagt teams om op vaste momenten te bekijken hoe ze effectiever kunnen worden, en hun gedrag daarop aan te passen. In Scrum is de Sprint Retrospective het event dat elke sprint afsluit.
Deze gids behandelt de vijf fases van een goede retrospective, hoe de bekendste werkvormen zich tot elkaar verhouden en een uitgewerkt voorbeeld waarin één team van post-its naar één vastgelegde verandering met een eigenaar gaat.
In het kort
Een retrospective heeft zijn werk gedaan als het team vertrekt met één concrete verandering, één eigenaar en een manier om te zien of het gewerkt heeft. Al het andere in de bijeenkomst dient om die verandering te vinden.
De Prime Directive
De meeste retrospectives beginnen met het herhalen van de Retrospective Prime Directive, geschreven door Norm Kerth in Project Retrospectives (2001). Kort gezegd: wat we ook ontdekken, we gaan ervan uit dat iedereen zijn best heeft gedaan met wat hij toen wist, zijn vaardigheden, de beschikbare middelen en de situatie van dat moment.
Hij is er niet om beleefd te zijn. Een team dat schuld verwacht, geeft veilige, algemene feedback en verzwijgt de echte oorzaak. Pas als schuld van tafel is, zegt iemand hardop: “Ik wist niet dat de specificatie was veranderd.” En met precies zo'n zin begint meestal het nuttige deel van de bijeenkomst.
De vijf fases van een retrospective
Esther Derby en Diana Larsen beschrijven in hun boek Agile Retrospectives vijf fases die bijna elke goede retrospective doorloopt, welke werkvorm je ook gebruikt:
| Fase | Doel | Gebruikelijke tijd in een retro van 45 minuten |
|---|---|---|
| 1. De toon zetten | Het doel en de Prime Directive herhalen; iedereen vroeg aan het woord laten | 5 minuten |
| 2. Gegevens verzamelen | Vastleggen wat er gebeurd is: feiten, gebeurtenissen en hoe mensen het beleefden | 10 minuten |
| 3. Inzichten genereren | De gegevens groeperen, het grootste thema kiezen en de grondoorzaak vinden | 15 minuten |
| 4. Bepalen wat je gaat doen | Een of twee veranderingen kiezen, elk met een eigenaar | 10 minuten |
| 5. Afsluiten | De afspraken bevestigen en checken hoe de bijeenkomst ging | 5 minuten |
De fase die teams het vaakst overslaan, is de derde. Wie rechtstreeks van “dit zijn onze post-its” naar “dit zijn onze acties” springt, krijgt acties die symptomen bestrijden.
Bekende werkvormen voor een retrospective
De werkvorm is de set vragen die je in fase 2 stelt. Door werkvormen af te wisselen, voorkom je dat een vaste retrospective een sleur wordt.
| Werkvorm | Vragen | Het meest geschikt voor |
|---|---|---|
| Start, Stop, Continue | Waar moeten we mee beginnen, waar mee stoppen en wat blijven we doen? | Nieuwe teams; snelle retro's |
| Starfish | Blijven doen, meer van, minder van, stoppen met, beginnen met | Teams die meer nuance willen dan “goed” en “slecht” |
| Mad, Sad, Glad | Waar was je boos, teleurgesteld of blij over? | Sprints die emotioneel zwaar waren |
| 4L's | Liked, Learned, Lacked, Longed for | Einde van een project of kwartaal |
| Zeilboot | Wind (wat hielp), ankers (wat ons afremde), rotsen (risico's verderop) | Teams die een risicovolle periode ingaan |
| Tijdlijn | De belangrijkste gebeurtenissen van de sprint uitzetten en dan de hoogte- en dieptepunten markeren | Evaluaties na een incident of release |
De Starfish, meestal toegeschreven aan Patrick Kua, is de werkvorm van onze gratis retrospective-template. De vijf categorieën laten ruimte voor “dit werkt, maar we overdrijven het”, wat bij een simpele indeling in goed en slecht verloren gaat.
Een uitgewerkt voorbeeld van een retrospective
Hier is een retrospective van 45 minuten voor een fictief productteam van zeven mensen. Hun sprint van twee weken eindigde ermee dat een exportfunctie voor klanten drie dagen te laat live ging.
Fase 1: De toon zetten (5 minuten)
De facilitator herhaalt de Prime Directive en benoemt het doel: “We hebben de export drie dagen te laat opgeleverd. Laten we uitzoeken waarom en één verandering afspreken voor de volgende sprint.” Iedereen vat de sprint samen in één woord. Twee mensen zeggen “gehaast”.
Fase 2: Gegevens verzamelen (10 minuten)
Het team zet snel een tijdlijn van de sprint op en schrijft daarna vijf minuten in stilte Starfish-notities, zodat niet de luidste stem de agenda bepaalt.
| Blijven doen | Meer van | Minder van | Stoppen met | Beginnen met |
|---|---|---|---|---|
| Dagelijkse stand-ups korter dan 15 minuten | Pairen op lastige stories | Ad-hoc designreviews in de chat | Acceptatiecriteria halverwege de sprint wijzigen | Ontwerpen vóór de sprint aan de klant laten zien |
| Tests schrijven vóór het mergen | Demo's voor de klant | Statusoverleggen die ook een bericht hadden kunnen zijn | Aan stories beginnen zonder definitieve mock-up |
Fase 3: Inzichten genereren (15 minuten)
Het team clustert de notities en stemt. Veruit het grootste cluster gaat over eisen die veranderden nadat de sprint al was begonnen. Het team past er de 5 x waarom-methode op toe:
- Waarom ging de export te laat live? Bij het testen bleek dat hij niet aansloot op wat de klant verwachtte.
- Waarom? De acceptatiecriteria veranderden op dag zes van de sprint.
- Waarom? De operationeel manager van de klant zag het ontwerp op dag vijf voor het eerst.
- Waarom? Ontwerpen worden intern beoordeeld, maar niet aan de klant getoond voordat een story de sprint ingaat.
- Waarom? Niemand is eigenaar van het akkoord van de klant. Product ging ervan uit dat accountmanagement het regelde, en accountmanagement ging ervan uit dat product het deed.
De grondoorzaak is niet “communicatie”. Het is een stap in het proces zonder eigenaar.
Fase 4: Bepalen wat je gaat doen (10 minuten)
Iemand stelt voor om “beter te communiceren met de klant”. De facilitator houdt dat tegen: dat is een wens, geen verandering. Het team spreekt in plaats daarvan één experiment af:
- Verandering: in de komende twee sprints heeft elke story met een wijziging die de klant ziet een door de klant beoordeelde mock-up nodig voordat hij de sprint ingaat.
- Eigenaar: de productmanager.
- Hoe we het merken: we tellen de stories waarvan de acceptatiecriteria veranderen nadat de sprint is begonnen. Vorige sprint waren dat er drie.
De overige notities gaan op een lijst om later op terug te komen. Het team verbindt zich aan één verandering, niet aan zeven.
Fase 5: Afsluiten (5 minuten)
De facilitator leest het experiment en de eigenaar nog eens voor, en iedereen geeft de retrospective een cijfer van één tot vijf. De volgende retrospective begint met het checken van de telling.
Waarom retrospectives mislukken
- Geen actie, of te veel. Een lijst met tien verbeteringen is een lijst waar niemand eigenaar van is. Kies er een of twee.
- Acties die wensen zijn. “Beter communiceren” kun je maandag niet uitvoeren. “De klant keurt mock-ups goed vóór de sprint” wel.
- De actie van de vorige keer nooit checken. Begint de volgende retrospective niet met een blik op de vorige verandering, dan leert het team dat afspraken vrijblijvend zijn.
- Schuld. Zodra één persoon wordt aangewezen, gaat iedereen anders op zijn woorden letten.
- Elke keer dezelfde werkvorm. Wissel de vragen af, zodat het team niet op de automatische piloot dezelfde antwoorden geeft.
Retrospectives helemaal overslaan heeft ook een prijs. Daarover lees je meer in de kosten van processchuld.
Retrospective vs. sprint review vs. post-mortem
Deze drie worden vaak door elkaar gehaald, omdat ze allemaal terugkijken:
- Sprint review: het team laat stakeholders zien wat het gebouwd heeft en haalt feedback op het product op.
- Retrospective: het team kijkt naar hoe het gewerkt heeft en past zijn proces aan. Stakeholders zijn er meestal niet bij.
- Post-mortem: een eenmalige evaluatie van een specifiek incident of een specifieke mislukking. Gebruikt vaak dezelfde fases, met een tijdlijn als middelpunt.
Gratis retrospective-template
De gratis retrospective-template is er als PDF, Word-document, Excel-werkmap en PowerPoint-presentatie. Hij gebruikt de Starfish-werkvorm, met vragen voor elk van de vijf categorieën en een actietracker voor eigenaren en datums.
Verder met retrospectives
- Zo leid je een projectretrospective: de houding van de facilitator en hoe je omgaat met een verhitte sfeer.
- Zo houd je een sprint retrospective in Microsoft Teams: een remote playbook van 45 minuten.
- De kosten van processchuld: waarom het overslaan van retrospectives teams vertraagt.
Veelgestelde vragen
Hoe vaak moet een team een retrospective houden?
Aan het eind van elke sprint, of elke twee tot vier weken voor teams die niet in sprints werken. Ook na een grote release of een incident is een retrospective gebruikelijk.
Hoe lang duurt een retrospective?
Ongeveer 45 minuten voor een sprint van twee weken. De Scrum Guide begrenst de Sprint Retrospective op drie uur voor een sprint van een maand en merkt op dat hij bij kortere sprints meestal korter is.
Wie doen er mee aan een retrospective?
De mensen die het werk gedaan hebben: het uitvoerende team, in Scrum inclusief de product owner en de Scrum Master. Managers en stakeholders blijven meestal weg, zodat iedereen vrijuit kan praten.
Wie faciliteert een retrospective?
Vaak de Scrum Master of een teamlid dat per keer wisselt. Afwisselen helpt, en bij een gespannen retrospective kan een externe facilitator de groep laten focussen op het proces in plaats van op personen.
Wat levert een retrospective op?
Een of twee concrete procesveranderingen, elk met een eigenaar en een manier om in de volgende retrospective te zien of ze gewerkt hebben.
Klaar om dit in de praktijk te brengen? Gebruik met je team de gratis template voor een retrospective.
