Wat is de Retrospective voor engineeringteams?
De Retrospective voor engineeringteams is gemaakt voor developers, QA, DevOps en engineering leads. Deze retrospective behandelt de technische kant van het werk, zoals codekwaliteit, tests, pipelines en technische schuld, en daarnaast de menselijke kant: hoe het team communiceerde, kennis deelde en omging met on-call. Het bord heeft vier kolommen, elk met een vraag. Wat ging goed? legt de werkwijzen en successen vast die je wilt behouden. Wat hield ons tegen? verzamelt de blokkades, frictie en technische schuld. Hoe werkten we samen? kijkt naar communicatie en onderlinge ondersteuning in het team. Wat proberen we hierna? zet de discussie om in een paar experimenten, elk met een eigenaar. In TeamRetro voegt iedereen tegelijk ideeën toe. Daarna groepeert het team ze, stemt het over wat het belangrijkst is en zet het de belangrijkste punten om in acties die je kunt opvolgen. Gebruik deze retrospective aan het einde van elke sprint, na een grote release of als vast evaluatiemoment, en houd het blameless, zodat mensen de flaky test die ze negeerden net zo makkelijk noemen als de refactor waar ze trots op zijn.
Format van de Retrospective voor engineeringteams
Wat ging goed?
Welke werkwijzen of successen willen we behouden?
Vraag door naar details: een architectuurkeuze die standhield, een soepele deployment, goed pairen, degelijke testdekking. Als je benoemt wat werkte, is het makkelijker om ermee door te gaan.
Wat hield ons tegen?
Welke blokkades, frictie of technische schuld remden ons af?
Breng knelpunten, technische schuld, onduidelijke requirements en frictie in het proces naar boven. Houd het blameless en zoek naar terugkerende problemen die het team realistisch gezien kan oplossen.
Hoe werkten we samen?
Hoe goed communiceerden we en steunden we elkaar?
Kijk naar hoe informatie werd gedeeld, of mensen zich gesteund voelden en hoe beslissingen tot stand kwamen. Beslissingen in privéberichten en overdrachten tussen tijdzones komen hier vaak naar voren.
Wat proberen we hierna?
Welke experimenten of verbeteringen spreken we af?
Vraag om concrete experimenten, aanpassingen in het proces of technische investeringen voor de volgende iteratie. Houd ze klein en meetbaar, met een eigenaar per actie, zodat je ze de volgende keer kunt nalopen.
Wanneer dient u deze retrospective te gebruiken?
- Aan het einde van elke sprint of iteratie, om engineeringpraktijken en oplevering te evalueren.
- Na een grote release, een incident of een productieprobleem, om lessen vast te leggen zonder schuld toe te wijzen.
- Als vast evaluatiemoment om technische schuld, knelpunten en frictie in de samenwerking op te sporen voordat ze groter worden.
- Bij de onboarding van nieuwe engineers of een wijziging in de teamstructuur, om afspraken te maken over de manier van werken.
Voorstellen voor ijsbrekers
- Als jullie codebase een stad was, wat voor plek zou het nu zijn?
- Zonder welke tool of technologie had je het deze sprint niet gered?
Wilt u een opwarmoefening waarbij uw team daadwerkelijk meedoet, en niet alleen hardop antwoorden geeft? Bekijk gratis ijsbrekers →
Ideeën en tips voor uw retrospectievevergadering
- Houd het blameless. Praat over systemen, processen en omstandigheden, niet over personen.
- Verzamel ideeën anoniem en tegelijk voordat de discussie begint, zodat stillere engineers net zoveel inbrengen als senioren.
- Gebruik dot voting om de onderwerpen met de meeste impact te kiezen en bewaar de rest voor een volgende sessie.
- Spreek een paar concrete acties af met een eigenaar en bespreek ze aan het begin van de volgende retrospective.
- Zet een timebox op elke kolom, zodat één technische discussie niet de hele sessie overneemt.
- Laat de rol van facilitator rouleren, zodat het team samen eigenaar is en het format fris blijft.