Sprint Retrospective: 6 valkuilen en wat wél werkt

De Sprint Retrospective is voor mij persoonlijk het krachtigste event in Scrum, als je het goed doet. Het is de plek waar een team van losse mensen langzaam een echt team wordt. Maar het is óók het event waar het vaakst de klad in zit: snel afgeraffeld na een vermoeiende review, één of twee mensen die domineren, en aan het eind geen concrete afspraken. Dit artikel is daarom geen samenvatting van wat in elke Scrum-cursus staat. Het zijn de zes valkuilen die we in ontelbare retros bij Nederlandse teams zien gebeuren, en de drie principes die wél altijd werken.

TL;DR. De Sprint Retrospective is het Scrum-event waarin het team na elke sprint reflecteert op samenwerking, proces en tools. Doel: één à twee concrete verbeteringen voor de volgende sprint. Maximaal 2 uur per twee-wekelijkse sprint, gefaciliteerd door de Scrum Master. Werkt alleen écht als iedereen aan het woord komt, discussies niet worden afgedekt en er een gedeelde actielijst overblijft die input is voor de volgende retro.

Wat is een Sprint Retrospective?

De Sprint Retrospective is het laatste van de vijf Scrum-events. Het Scrum Team (Product Owner, Scrum Master en de Developers samen) komt na elke Sprint Review bij elkaar om terug te kijken: wat ging goed, wat ging niet goed, wat gaan we anders doen? Volgens de Scrum Body of Knowledge mag de retrospective maximaal 2 uur duren voor een twee-wekelijkse sprint.

De Scrum Master faciliteert de retrospective. Dat betekent niet dat hij of zij vertelt wat het team moet vinden, wel dat het event productief, veilig en op tijd verloopt, en dat afspraken concreet worden vastgelegd.

Verschil met de Sprint Review: de Sprint Review gaat over het product (wat hebben we gemaakt, wat vinden stakeholders ervan?). De Retrospective gaat over het proces en het team (hoe werken we samen, wat kunnen we beter doen?). Dat onderscheid is essentieel - zie ook de eerste valkuil verderop.

Wat een retrospective écht oplevert

Mensen die voor het eerst in een Scrum team zitten, lopen in de eerste paar sprints onvermijdelijk tegen dezelfde drempel aan: teamdynamiek. Bruce Tuckman beschreef dat al in 1965: eerst forming (kennismaken), dan storming (de wrijving die ontstaat als verschillende mensen, gewoontes en verwachtingen op elkaar botsen). Dat storming kun je niet skippen. Wat je wel kunt doen: het zichtbaar maken en bespreekbaar.

In ontelbare retros komt na de eerste twee à drie sprints hetzelfde patroon terug. Ergens loopt iemand vast, deelt het niet, en doet daarna geen werk meer of doet het verkeerde werk. Het komt pas op tafel in de review of erna, en dan is er ruzie of frustratie. In de retrospective wordt dat dan een collectief inzicht: we moeten beter en eerder met elkaar communiceren. Drie concrete afspraken die we teams keer op keer zelf zien formuleren:

1. Als je vastloopt, deel het tijdens de daily standup. Hoe eerder je het zegt, hoe eerder iemand anders je kan helpen. Wachten tot het einde van de sprint is een keuze.
2. Vraag een teamlid om mee te kijken voordat je iets als "klaar" markeert. Twee zien meer dan een. Die peer-review vóór de Sprint Review vangt kleine fouten af die anders bij stakeholders aan tafel terechtkomen.
3. Hou de standup op een vaste tijd en cadans. Voor sommige teams klinkt dat als overhead. In de praktijk is het juist het tegenovergestelde: zonder vaste cadans wordt de standup overgeslagen en gaan dingen langer ondergronds.

Geen van die drie afspraken zijn revolutionair. Wat wel revolutionair is: een team komt er zelf op door zijn eigen sprint te onderzoeken. Dat is wat een goede retrospective oplevert. Niet de afspraken zelf, maar het inzicht waarom ze nodig zijn.

De 6 patronen die we vaak fout zien gaan

In vrijwel elke retrospective waar het misgaat, kun je een van de volgende zes patronen herkennen. Niet allemaal tegelijk, meestal één of twee. Maar ze zijn structureel: ze komen terug bij verschillende teams en verschillende organisaties. De Scrum Master die ze herkent kan ze adresseren voordat ze het event laten ontsporen.

1. Afraffelen na de Sprint Review

Dit is de allerergste. Na de review is iedereen moe. Het team is twee uur lang aan het presenteren geweest, vragen aan het beantwoorden, energie aan het geven. Dan staat de retro nog op de agenda, vaak direct erna. Iedereen knikt 'ja, ging goed, niets te melden', en gaat naar huis. Needless to say: dit is een gemiste kans op een kwaliteitsslag van het team.

Wat we teams aanraden: plan de retrospective op een ander dagdeel dan de Sprint Review, of zelfs op de volgende ochtend. De energie die je nodig hebt om eerlijk te reflecteren is een andere dan die om aan stakeholders te presenteren.

2. Eén of twee senioren domineren het gesprek

Sommige teamleden zijn van nature sneller met spreken. Anderen denken eerst, zeggen dan iets. In een retro zonder structuur winnen de eersten altijd. De juniors, de stillere mensen, de nieuwe teamleden: zij komen niet aan bod. Maar júíst hun observaties zijn vaak het meest waardevol, omdat ze nog niet zijn afgestompt voor wat er gebeurt.

Wat we teams aanraden: als Scrum Master nodig je expliciet uit. "Joh, ik heb jou nog niet gehoord, wat vind jij ervan?" Zo simpel. Geen ronde-de-tafel rituelen, geen sticky notes-als-trucje. Direct vragen.

3. Niemand durft zich uit te spreken

Dit is geen verlegenheidsprobleem, het is een veiligheidsprobleem. Als de retro alleen oppervlakkige opmerkingen oplevert ('ging best goed', 'communicatie kan beter'), zit er iets onder. Vaak: angst voor consequenties als je iets concreets benoemt. Of een trauma uit een eerder team waar eerlijkheid werd afgestraft.

Wat we teams aanraden: als Scrum Master begin je met je eigen kwetsbaarheid te tonen. "Ik merkte deze sprint dat ik te vaak heb laten gaan dat de standup uitliep. Daar moet ik anders mee omgaan." Het kost één retro om de toon te zetten. Anders blijft het oppervlakkig.

4. Geen concrete actielijst aan het einde

De retro is voorbij, iedereen heeft gepraat, er zijn inzichten. Maar er is geen lijstje waar het team de volgende sprint mee aan de slag gaat. Zonder dat lijstje is de retro een gezellig moment geweest - meer niet. De volgende sprint loopt iedereen tegen exact dezelfde dingen aan.

Wat we teams aanraden: sluit altijd af met maximaal twee à drie expliciete acties. Wie doet wat, tegen wanneer, hoe controleren we dat het is gebeurd. Schrijf het op een plek die iedereen ziet (het team-board, een vaste pagina in Confluence). Open de volgende retro met deze lijst: wat is gedaan, wat niet, en waarom?

5. Alleen externe factoren worden besproken

'De stakeholders waren onduidelijk', 'de DevOps-afdeling is te traag', 'we hebben nog geen toegang tot dat systeem'. Allemaal mogelijk waar. Maar als de retro alléén over factoren buiten het team gaat, dan ontwijkt het team de eigen verantwoordelijkheid voor verbetering.

Wat we teams aanraden: als Scrum Master leid je het gesprek terug. "Oké, gegeven dat de stakeholders onduidelijk zijn, wat kunnen wij als team daar anders mee doen?" De externe factor staat vast voor nu. De vraag is wat het team eraan gaat doen.

6. De Product Owner is aanwezig

Dit is een controversiële. Volgens de Scrum Guide is de PO onderdeel van het Scrum Team en dus welkom in de retro. In de praktijk werkt het vaak averechts. De PO is degene die scoping doet, prioriteiten zet, soms onder druk van stakeholders. Zijn aanwezigheid maakt het gesprek snel inhoudelijk in plaats van team-gericht. "Hoe gaan we de volgende sprint plannen?" in plaats van "hoe werken we samen?"

Wat we teams aanraden: als de teamveiligheid nog jong is, doe de retro zonder PO. De PO sluit aan bij de Sprint Planning om de uitkomsten te horen. Naarmate het team rijper wordt en veiligheid is opgebouwd, kan de PO weer aansluiten. Dit is geen Scrum-orthodoxie, dit is wat in NL meestal beter werkt.

De drie principes die altijd werken

De vormen van een retrospective zijn eerlijk gezegd ondergeschikt. Wat we in vijftien jaar facilitatie hebben geleerd is dat drie principes altijd het verschil maken, ongeacht de vorm:

Zorg dat iedereen aan het woord komt

Niet alleen wachten tot mensen iets zeggen, maar expliciet uitnodigen. "Wat vind jij ervan?" is een complete zin. Vaak vergeten Scrum Masters de stillere helft van het team. Dat is geen luxe - dat is waar de meeste inzichten verstopt zitten.

Discussies niet afdekken

Een retro waarin verschillen worden gladgestreken om de sfeer goed te houden, levert niets op. De storming-fase die Tuckman beschrijft moet je niet ontwijken; je moet erdoorheen. Een korte discussie tijdens een retro brengt het team door de storming-fase sneller heen dan tien retros waarin alles 'wel oké' is.

Gedeelde actielijst die input is voor de volgende retro

Geen losse acties die ergens verdwijnen. Geen voornemens die je niet kunt narekenen. Eén lijstje, maximaal twee à drie items, eigenaar per item, datum waartegen het gebeurt. En in de volgende retro is de eerste agenda-punt: wat staat er op het lijstje, en wat hebben we ermee gedaan?

Drie principes, en bijna alles dat verder in dit artikel staat, is een uitwerking ervan.

Vormen voor afwisseling (en waarom de basisvorm bijna altijd genoeg is)

Veel artikelen over retrospectives gaan over vormen: Start-Stop-Continue, Mad-Sad-Glad, 4 L's, Sailboat, Speed Boat, Lean Coffee, 5 Whys, Constellation. Op internet kun je tientallen vormen vinden, vaak met sjablonen in tools als Miro of Funretro.

Maar in Nederlandse teams werkt dit anders dan veel artikelen suggereren. De Nederlandse cultuur is direct. Mensen zeggen wat ze vinden, zonder veel omhaal. De metaforische vormen (Sailboat met wind in de zeilen en anker dat tegenhoudt, of Speed Boat met anker, wind en ijsbergen) zijn ontwikkeld voor cultures waar mensen het lastig vinden om direct kritiek te uiten. In die context geeft de metafoor een veilige indirecte route.

In NL hoef je dat zelden te doen. Het basisformat (wat ging goed, wat ging niet goed, wat gaan we anders doen) werkt in de meeste teams uitstekend, mits de drie principes hierboven op orde zijn.

Drie vormen die wel toegevoegde waarde hebben

Voor wie wel wil variëren, bijvoorbeeld omdat de retro elke sprint hetzelfde voelt, zijn dit de drie die werken:

• Start, Stop, Continue. Wat moeten we gaan doen, wat moeten we stoppen, wat moeten we blijven doen? Werkt voor bijna elk team, in elke fase. Genoeg structuur om alles boven tafel te krijgen, weinig overhead.
• Mad, Sad, Glad. Waar ben je boos over, verdrietig, blij? Werkt als je vermoedt dat het team op iets emotioneels zit. De woorden 'boos' en 'verdrietig' geven mensen permission om iets te benoemen dat anders niet boven komt.
• 4 L's (Liked, Learned, Lacked, Longed for). Wat vond je fijn, wat heb je geleerd, wat miste je, waar verlang je naar? Werkt voor rijpere teams die al door de storming-fase heen zijn en nu willen verfijnen. De vraag 'wat miste je' brengt vaak onverwachte inzichten naar boven.

De andere vormen zijn nuttig om in je achterzak te hebben, maar in de praktijk zijn dit de drie waarmee je 90% van de retros prima invult.

Retrospectives in remote en hybride teams

Er is één ding dat we in tien jaar remote work geleerd hebben: mensen worden geen ECHT team als je ze niet van tijd tot tijd fysiek bij elkaar zet. Zeker in het begin. Een nieuw team dat alleen via Zoom werkt, blijft een groep individuen.

Is alléén remote retros doen onmogelijk? Nee. Maar het werkt alleen bij teams die al écht op elkaar zijn ingespeeld en elkaar van tijd tot tijd ook fysiek in de ogen kunnen kijken. Bij nieuwe teams is ons advies: organiseer de eerste paar retros fysiek, zelfs als de rest van het werk remote is.

Regels voor online retros

• Iedereen in beeld. Geen 'mijn webcam doet het niet vandaag'-mensen. Geen luistermodus. Iedereen, hele tijd.
• Goede opstelling van je webcam. Bovenaan het scherm, met net daaronder je eigen Zoom-scherm. Zo kun je deelnemers daadwerkelijk aankijken in plaats van naar de zijkant te kijken. Klinkt klein, is groot verschil in hoe verbonden het gesprek voelt.
• Whiteboard functioneel in beeld. Als je Miro of een vergelijkbaar bord gebruikt, zet het niet de hele meeting op het scherm. Schakel tussen 'mensen in beeld' (voor het gesprek) en 'whiteboard in beeld' (wanneer je iets gezamenlijk vastlegt).

Een retrospective-agenda die werkt

Voor wie een concrete agenda zoekt, dit is wat in vrijwel elk team goed werkt:

Onderdeel	Tijd	Wat gebeurt er
Check-in	5 min	Hoe zit iedereen erbij? Eén woord per persoon.
Acties vorige retro	10 min	Wat hebben we ermee gedaan? Wat is open?
Wat ging goed	15 min	Iedereen aan het woord. Scrum Master vraagt door bij stilte.
Wat ging niet goed	30 min	Inclusief discussie. Niet afdekken.
Acties komende sprint	15 min	Maximaal 2-3 acties, eigenaar per actie, deadline.
Check-out	5 min	Eén ding dat iemand meeneemt.

Totaal: 80 minuten. Voor een 2-wekelijkse sprint precies goed; voor een maand-sprint kun je elke fase 50% verlengen.

Veelgestelde vragen

Hoelang duurt een retrospective?

Volgens de Scrum Body of Knowledge maximaal 2 uur voor een twee-wekelijkse sprint. In de praktijk lukken de meeste effectieve retros binnen 60-90 minuten, mits goed gefaciliteerd.

Hoe vaak doe je een retrospective?

Eén keer per sprint, aan het einde. Voor de meeste teams dus elke twee weken. Geen extra retros tussendoor, die zijn meestal een teken dat iets in de sprint zelf niet werkt (te lange feedback-cyclus).

Wat is het verschil tussen een retrospective en een sprint review?

De Sprint Review gaat over het product: wat hebben we gemaakt, wat vinden stakeholders ervan, wat is de volgende stap? De Retrospective gaat over het proces en het team: hoe werken we samen, wat kunnen we beter doen?

Mag de manager bij de retrospective?

Nee. De retro is alleen voor het Scrum Team (Product Owner, Scrum Master, Developers). Aanwezigheid van een lijnmanager of stakeholder vernietigt de psychologische veiligheid die het event nodig heeft. Als de manager iets wil horen, krijgt hij of zij een samenvatting van de acties, niet het proces.

Wat als het team niet open durft te zijn?

Dan zit er iets onder. Vaak een eerder gebrek aan veiligheid, een team dat een keer is afgestraft voor eerlijkheid. Als Scrum Master begin je met je eigen kwetsbaarheid: vertel zelf iets dat niet goed ging. Bouw veiligheid stap voor stap op. Dwing geen eerlijkheid af; faciliteer ze.

Welke tools werken het beste voor remote retros?

Miro en Mural zijn de meest gebruikte whiteboards in NL. Funretro en Retrium zijn retro-specifieke tools. Welk tool je kiest is minder belangrijk dan dat het Scrum Team er comfortabel mee is. Wissel niet elke retro van tool, wennen kost tijd.

Retrospectives faciliteren leren

Een retrospective goed faciliteren is een vak op zich. Het vraagt om observatie, timing, en het lef om in te grijpen als een patroon zich aan het herhalen is. Onze Scrum Master Training besteedt uitgebreide aandacht aan retrospective-facilitatie, inclusief de zes patronen uit dit artikel.

Eerst meer lezen? Bekijk hoe de retrospective past in het bredere Scrum-framework via onze gids Wat is Scrum? of lees meer over de rol van de Scrum Master die deze retros faciliteert.