Retrospective technische schuld

Vind, rangschik en los je technische schuld planmatig af

Probeer deze retrospective live eens

Bronnen van schuld

Welke delen van de codebase hebben technische schuld opgebouwd?

De authenticatiemodule is veel te complex en lastig te onderhouden door alle hacks en workarounds die er in de loop der tijd in zijn geslopen.
We hebben veel gedupliceerde code in verschillende componenten die we zouden moeten refactoren naar gedeelde utilities.
Veel van onze kerndatamodellen zijn sterk aan elkaar gekoppeld, dus elke uitbreiding of aanpassing geeft kans op regressies.
Impact en risico's

Wat doet deze technische schuld met het team en het product?

Nieuwe developers inwerken is ontzettend lastig door de complexiteit en het gebrek aan documentatie in bepaalde delen.
We zijn constant brandjes aan het blussen en krijgen nieuwe features niet in een redelijk tempo af, omdat de schuld voor instabiliteit zorgt.
Ons deploymentproces is fragiel en foutgevoelig, met regelmatig productieproblemen en storingen als gevolg.
Prioriteren

Welke schuld moeten we als eerste aanpakken?

We moeten beginnen met de authenticatiemodule, want dat is een kernafhankelijkheid die meerdere delen van de applicatie raakt.
Betere testdekking voor onze meest veranderlijke componenten geeft een stevige basis voor toekomstige refactoring.
Het upgraden van de frontend naar de nieuwste React-versie moet topprioriteit hebben, zodat we profiteren van betere performance en nieuwe features.
Actieplan

Hoe pakken we de geprioriteerde schuld systematisch aan?

We reserveren 20% van elke sprint voor schulditems met hoge prioriteit, te beginnen met de refactor van de authenticatiemodule.
Om de week houden we een speciale 'aflosdag' voor stapsgewijze verbeteringen op basis van de prioriteiten.
Het komende kwartaal wordt één senior developer volledig vrijgemaakt om het terugdringen van onze technische schuld te leiden.

Wat is een retrospective over technische schuld?

Een retrospective over technische schuld is een gerichte sessie waarin je team de schuld in de codebase of het systeem in kaart brengt, het eens wordt over wat die kost en besluit wat als eerste wordt afgelost. Je sluit af met een plan met eigenaren en data. Technische schuld is de opeenstapeling van shortcuts en minder ideale oplossingen in een codebase. Een deel ontstaat doordat snelle oplevering voorrang kreeg boven kwaliteit op de lange termijn, een deel door gaten in kennis en een deel door refactoring die steeds werd uitgesteld. Doe je er niets aan, dan wordt elke wijziging trager en riskanter. Het bord heeft vier kolommen. Bij Bronnen van schuld benoemen mensen de concrete probleemgebieden: verknoopte modules, gedupliceerde code, ontbrekende tests, verouderde frameworks. Impact en risico's gaat over wat die schuld doet met oplevering, kwaliteit, onboarding en moraal. Bij Prioriteren rangschik je de items op impact, inspanning en belang. Het Actieplan zet de belangrijkste items om in werk met eigenaren, tijdlijnen en controlemomenten, bijvoorbeeld een vast deel van elke sprint dat voor aflossing is gereserveerd. Houd deze retrospective ongeveer elk kwartaal, of wanneer het team merkt dat schuld het werk vertraagt, zodat de schuld zichtbaar en klein blijft.

Format voor de retrospective technische schuld

Bronnen van schuld

Welke delen van de codebase hebben technische schuld opgebouwd?

Vraag mensen concreet te zijn over het soort schuld en waar die zit: code smells, architectuurproblemen, ontbrekende tests, verouderde dependencies.

Impact en risico's

Wat doet deze technische schuld met het team en het product?

Bespreek wat de schuld echt kost: tragere oplevering, bugs die klanten zien, moeizame onboarding, gefrustreerde developers. Concrete kosten maken duidelijk waarom aflossen nodig is.

Prioriteren

Welke schuld moeten we als eerste aanpakken?

Rangschik de schulditems op impact, inspanning en hoeveel ander werk ze blokkeren. Een snelle impact-versus-inspanningmatrix helpt het team om tot overeenstemming te komen.

Actieplan

Hoe pakken we de geprioriteerde schuld systematisch aan?

Maak een concreet plan: wie doet wat, wanneer, en wanneer kijken jullie naar de voortgang. Spreek af hoeveel capaciteit per sprint naar aflossing gaat.

Wanneer dient u deze retrospective te gebruiken?

  • Als je codebase met elke wijziging lastiger te onderhouden en uit te breiden wordt.
  • Als het team vooral brandjes blust en nieuwe features steeds uitlopen door instabiliteit.
  • Als het inwerken van nieuwe developers traag gaat omdat sommige delen ingewikkeld of ongedocumenteerd zijn.
  • Als onderhoud en bugfixes meer tijd kosten dan nieuw werk.
  • Als developers sprint na sprint gefrustreerd raken door dezelfde probleemgebieden.

Voorstellen voor ijsbrekers

  • Als onze codebase een gebouw was, hoe zou het eruitzien en waarom?
  • Wat is je grappigste of pijnlijkste ervaring met technische schuld?

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 gesprek vrij van schuldvragen. Elke codebase bouwt schuld op; de vraag is wat je er nu aan doet.
  • Zorg dat niet-technische deelnemers begrijpen wat technische schuld is en waarom het uitmaakt voor de oplevering.
  • Rangschik schuld op impact, inspanning en belang in plaats van alles tegelijk te willen oplossen.
  • Geef het plan tijdlijnen, eigenaren en vaste controlemomenten, zodat het niet stil komt te liggen.
  • Reserveer een vast deel van elke sprint of cyclus voor het aflossen van schuld.
  • Automatiseer linting, testen en delen van de code review, zodat er minder nieuwe schuld bijkomt.

Veelgestelde vragen

Wat is een retrospective over technische schuld?
Het is een gerichte teamsessie om te ontdekken waar technische schuld zich heeft opgebouwd, te bespreken wat die kost, te bepalen wat als eerste aangepakt moet worden en te plannen hoe je die aflost.
Wanneer houd je een retrospective over technische schuld?
Houd er een als je merkt dat de oplevering vertraagt, dezelfde bugs terugkomen of er een stapel shortcuts uit eerdere beslissingen ligt. Veel teams houden hem ook op een vast ritme, bijvoorbeeld eens per kwartaal, naast hun gewone sprintretrospectives.
Hoe prioriteer je technische schuld in de retrospective?
Geef elk item een score op impact, inspanning en belang in plaats van alles tegelijk aan te pakken. Zet de belangrijkste items daarna om in een actieplan met eigenaren en tijdlijnen.
Wie moet er bij een retrospective over technische schuld aanwezig zijn?
De developers die in de code werken, plus de product owner of degene die de prioriteiten bepaalt. Is degene die beslist wat er gebouwd wordt er niet bij, dan krijgt het plan zelden tijd in de sprint.
Hoeveel tijd moeten we besteden aan het aflossen van technische schuld?
Er is niet één juist getal. Veel teams reserveren een vast deel van elke sprint, zodat er gestaag wordt afgelost in plaats van te wachten op een speciale opruimsprint die er nooit komt.

Gerelateerde sjablonen

Bugfixing-retrospective

Ontdek waarom bugs ontstaan en voorkom dat ze terugkomen

DevOps-retrospective

Evalueer deployments, incidenten en overdrachten tussen dev en ops.

Code review retrospective

Maak de code reviews van je team sneller en nuttiger

Retrospective Productontwikkelingsproces

Kijk verder dan sprints en evalueer hoe je producten bouwt.

Bent u klaar om deze retrospective te houden?Probeer deze retrospective live eens