020 2614 195
slim
samen
werken

Technical debt: wat het is en wat je ermee doet

Stel je dit even voor. Je team levert sprint na sprint nieuwe features op, maar toch voelt elke sprint zwaarder dan de vorige. Kleine wijzigingen kosten ineens dagen. Bugs blijven terugkomen. En ergens in het team valt de zin: “Ja… dat is technical debt.” Maar wat bedoelen we daar nou écht mee? En misschien nog belangrijker: wat doe je ermee?

In deze blog:

Wat is technical debt?

Technical debt is eigenlijk een verrassend behulpzame metafoor. Het ontstaat op het moment dat je als team kiest voor een snelle oplossing in plaats van de beste oplossing. Je wint tijd op de korte termijn, maar je gaat een schuld aan. En zoals bij elke schuld betaal je rente.
Die rente betaal je niet in de vorm van geld, maar als:

  • extra werk
  • frustratie
  • vertraging

Om dit te illustreren, gebruik ik het volgende voorbeeld:

Je bouwt een bootje om het water over te steken. Dat bevalt goed, dus je wilt het gebruiken voor andere toepassingen. Je wilt meer mensen of extra lading meenemen of langere afstanden afleggen. Maar hiervoor is het bootje te licht en het zinkt bijna, dus je maakt er extra luchtkussens aan. Hierdoor vaart het langzaam, en het sturen kost veel moeite. Dit kost extra tijd en brandstof en het wordt pas opgelost als het bootje structureel wordt verbeterd.

Het is belangrijk om op te merken dat technical debt niet per definitie slecht is. Soms is het zelfs een bewuste en verstandige keuze. Je moet iets snel live hebben, een deadline is keihard of je wilt eerst leren of iets überhaupt waarde heeft. Dat kan prima zijn, zolang je maar weet dat je schuld opbouwt en afspreekt wanneer je die weer aflost.

En precies daar gaat het vaak mis.

Hoe ontstaat technical debt in de praktijk?

In theorie is technical debt een bewuste keuze. In de praktijk ontstaat het vaak sluipender.
Veelvoorkomende oorzaken zijn:

  • Korte-termijndenken door drukke deadlines
  • Veranderende wensen van stakeholders
  • Werken met nieuwe technologie zonder voldoende kennis
  • Testen overslaan “omdat we nu echt moeten leveren”

Het klassieke voorbeeld is die snelle demo. Even een shortcut nemen, even iets erin hacken. “Dat ruimen we later wel op.” Alleen: later komt zelden vanzelf. En voor je het weet bestaat je codebase uit een verzameling onafgemaakte shortcuts uit het verleden.

Wat is de impact van technical debt?

Technical debt vertraagt je team. Elke wijziging kost meer tijd, omdat eerst uitgezocht moet worden hoe alles ooit bedoeld was. Het wordt vooral gevoeld door de Developers: onderhoud wordt duurder en bugs oplossen voelt als Jenga spelen: je haalt één blokje weg en ergens anders stort iets in. In het uiterste geval ben je alleen nog maar bezig met onderhoud en kom je aan vernieuwing niet meer toe. Op de lange termijn kan technical debt het product zelfs instabiel maken en dan heb je echt een probleem.

Op de lange termijn zie je nog een ander effect: frustratie. Teams zijn steeds meer bezig met repareren in plaats van met waarde leveren. Dat is funest voor motivatie, voorspelbaarheid en uiteindelijk ook voor je product.

Technical debt is dus geen abstract IT-probleem. Het is een productprobleem. En daarmee een verantwoordelijkheid van het hele Scrum Team.

Hoe ga je er gezond mee om?

De eerste stap is simpel, maar cruciaal: maak technical debt zichtbaar.

  • Dat kan onder andere door:
  • Regelmatige code reviews
  • Geautomatiseerde tests
  • Tools die complexiteit, onderhoudbaarheid en risico’s inzichtelijk maken

Maar zichtbaar maken alleen is natuurlijk niet genoeg. Je moet er ook iets mee doen. Binnen Scrum is daar een heel logisch moment voor: de Sprint Retrospective. Dat is dé plek om samen te bespreken:

  • Waar zit technical debt?
  • Wat is de impact?
  • Wat gaan we ermee doen?

Niet om te klagen, maar juist om bewuste keuzes te maken. Het resultaat van deze sessie kan zó op de backlog om meegeprioriteerd te worden.

Technical debt binnen Agile en Scrum

Scrum gaat uit van onzekerheid. We weten niet alles vooraf. Daarom inspecteren en passen we elke sprint aan. Technical debt past precies in dat gedachtegoed, mits je er bewust mee omgaat. Dat betekent dat technical debt thuishoort op de Product Backlog, dat maakt het transparant. Op die manier kan de Product Owner samen met het team afwegingen maken.

Afwegingen zoals: investeren we nu in nieuwe functionaliteit, of maken we eerst het product gezonder? Dit kun je overigens heel eenvoudig praktisch maken door in de acceptatiecriteria van een story die technical debt veroorzaakt op te nemen: “er is een nieuwe user story voor het opruimen van de tech debt aangemaakt”.

Refactoring als vast onderdeel van je werk

Refactoring speelt hierbij een grote rol. Kleine, continue verbeteringen aan de code, zonder dat de functionaliteit verandert. Zie het als elke sprint een beetje opruimen, in plaats van eens per jaar een grote schoonmaak die nooit echt afkomt.

Een handige hulpmiddel hierbij is de 80/20-regel: vaak veroorzaakt een klein deel van de code het grootste deel van de problemen. Dáár wil je je aandacht op richten.

meer info product owner training

De vier kwadranten van technical debt

Om betere beslissingen te nemen, helpt het om technical debt te plaatsen langs twee assen:

bewust vs. onbewust
snel vs. langzaam ontstaan

Dat levert vier soorten schuld op:

  • Bewust en snel: soms prima, zolang je een plan hebt om het op te lossen
  • Onbewust en snel: vaak het gevolg van gebrek aan kennis
  • Bewust en langzaam: herkenbaar, maar meestal laag op de prioriteitenlijst
  • Onbewust en langzaam: de gevaarlijkste vorm, want die zie je pas als het bijna te laat is

Door dit onderscheid te maken, kun je veel gerichter bepalen waar je nu in moet investeren en wat nog even kan wachten. Dat is een mooi handvat voor de Product Owners onder ons!

Tot slot

Technical debt is onvermijdelijk. Onbeheerde technical debt is een keuze.

Door het zichtbaar te maken, erover te praten en er structureel aandacht aan te besteden, houd je niet alleen je product gezond, maar ook je team.

Vond je deze blog waardevol maar zit je nog wel met vragen? Neem dan contact op via info@agilescrumgroup.nl of 020 2614 195, en we helpen je graag verder.

Ook interessant:

Over de auteur: Bart Schrap

Bart is Agile coach en trainer bij Agile Scrum Group. Hij wordt er blij van om praktische dingen te maken, die echt van waarde zijn. En deze vervolgens continu te verbeteren. Vanuit een brede praktijkervaring traint en coacht hij mensen en teams om Agile te werken. Als Bart niet aan het werk is, rijdt hij op zijn motor of op zijn mountainbike. Hij houdt ervan om de natuur in te trekken.