Wat ging goed?

Welke werkwijzen of successen willen we behouden?

Onze geautomatiseerde testsuite ving twee regressies af voordat ze in productie kwamen.
Pair programming op de auth-refactor ging echt soepel.
De CI-pipeline was de hele sprint snel en betrouwbaar, zonder flaky builds.
Wat hield ons tegen?

Welke blokkades, frictie of technische schuld remden ons af?

Door flaky integratietests moesten we builds meerdere keren opnieuw draaien.
Onduidelijke acceptatiecriteria zorgden voor herwerk laat in de sprint.
Te veel schakelen tussen bugfixes en featurewerk.
Hoe werkten we samen?

Hoe goed communiceerden we en steunden we elkaar?

De kennisdeling tijdens onze tech talk op vrijdag was echt nuttig.
Sommige beslissingen werden in DM's genomen en de rest van ons miste de context.
De onboarding van onze nieuwe engineer ging soepel dankzij goede documentatie.
Wat proberen we hierna?

Welke experimenten of verbeteringen spreken we af?

Een WIP-limiet invoeren om minder te hoeven schakelen.
Elke sprint een vaste dag voor technische schuld inplannen.
Overstappen op trunk-based development om reviewcycli korter te maken.

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.

Veelgestelde vragen

Hoe lang duurt een Retrospective voor engineeringteams?
De meeste teams zijn er 45 tot 60 minuten mee bezig. Voor een groter team of na een grote release kun je tot 90 minuten uittrekken.
Wanneer houden we een Retrospective voor engineeringteams?
Aan het einde van elke sprint of iteratie werkt het best, maar je kunt hem ook houden na een belangrijke release of een incident, of als periodiek evaluatiemoment.
Wat is het verschil met een gewone Sprint Retrospective?
De principes zijn hetzelfde, maar de vragen zijn gericht op engineeringzaken zoals codekwaliteit, technische schuld, pipelines en hoe developers samenwerken.
Wie neemt deel aan de retrospective?
Iedereen die bij de oplevering betrokken is: developers, QA, DevOps en engineering leads. Als je het bij het kernteam houdt, is een open gesprek makkelijker.
Hoe houden we de retrospective blameless?
Spreek als basisregel af dat je systemen en processen verbetert en geen mensen beoordeelt. Doordat je in TeamRetro anoniem ideeën kunt verzamelen, is het makkelijker om eerlijk te zijn.
Hoe zorgen we ervoor dat actiepunten echt worden uitgevoerd?
Beperk je tot twee of drie concrete acties, geef elke actie een duidelijke eigenaar en bespreek de voortgang aan het begin van je volgende retrospective.
Bent u klaar om deze retrospective te houden?Probeer deze retrospective live eens