4 tips om beter om te gaan met technische schuld in Scrum

Technische schuld, of Technical debt, is één van de grootste frustraties van de Development Teams waar ik mee werk. De meeste teams steken meteen van wal wanneer je vraagt om voorbeelden van technische schuld in hun codebase. Dan heb ik het over work-arounds, moeilijk te lezen code, tijdelijke-maar-niet-heus oplossingen en andere hacks die op korte termijn een probleem oplossen, maar op langere termijn voor hoofdpijn zorgen. Development Teams zijn zich zeer bewust van de opbouw van technische schuld, maar voelen zich vaak machteloos om er wat aan te veranderen. Het lukt ze niet om goed uit te leggen waarom het bestrijden en voorkomen van technische schuld een belangrijk aandachtspunt is bij productontwikkeling. Het gevoel is vooral dat 'het management de voorkeur blijft geven aan meer nieuwe features boven goede code'.

In deze post geef ik je vier praktische tips om technische schuld transparant te maken, en hoe je je organisatie helpt om een betere balans te treffen tussen code kwaliteit en nieuwe features.

1. Maak gebruik van krachtige metaforen

'Technische schuld' is een krachtige metafoor. Gebruik het ook zo. De consequentie van hacks, work-arounds die 'nu snel een probleem oplossen, maar later hoofdpijn veroorzaken' is abstract en moeilijk te begrijpen voor niet-developers. Ze hebben simpelweg geen mentaal model om te begrijpen wat 'technische schuld' is en wat het veroorzaakt. Het constant benadrukken dat 'X verbeterd zou moeten worden' of dat 'Y slechte code' is, gaat hier niet helpen. Het zorgt er eerder voordat dat je wordt weggezet als 'die gast die altijd loopt te mopperen'.

Metaforen zorgen voor begrip omdat ze een mentaal model bieden. 'Technische schuld' is zo'n metafoor. Oorspronkelijk bedacht door Ward Cunningham, en verder uitgewerkt door Martin Fowler, stelt het het schrijven van code van lage kwaliteit gelijk aan het opbouwen van een financiële schuld. Technische schuld bouwt op wanneer slechte code wordt geschreven vanuit de gedachte om het later te verbeteren. Omdat code slecht te lezen is, buggy in elkaar steekt of niet goed getest is, zorgt het ervoor dat je rente gaat betalen over deze code. Rente die bestaat uit vertraging, bugs en verloren tijd. En net als bij een financiële schuld stapelen de gevolgen van deze rente zich op. Totdat je alleen nog maar rente aan het betalen bent. Alle tijd gaat dan naar het oplossen van bugs, het doorgronden van moeilijk leesbare code, het dichten van security holes en het oplossen van performance-problemen. Natuurlijk accepteren we soms een mate van technische schuld, en de rente die er uit komt, maar veel moeten we dat niet willen. De volgende visualisatie illustreert het gevolg van technische schuld dan ook uitstekend:

2. Neem verantwoordelijkheid als Development Team

Soms voelen Development Teams zich slachtoffer van de wijze waarop het management aan de ene kant de prioriteit blijft geven aan nieuwe features boven het bestrijden van technische schuld, terwijl het team aan de andere kant wel de schuld krijgt van bugs, performance-problemen en steeds tragere ontwikkeling.

Een belangrijke eerste stap is om uit de slachtofferrol te stappen. Neem als Development Team de verantwoordelijkheid over het voorkomen en bestrijden van technische schuld. Het is niet zonder reden dat de Scrum Guide het Development Team verantwoordelijk maakt voor het garanderen van kwaliteit. Maak gebruik van de tips in deze post om techische schuld op de agenda te krijgen. Maak het transparant. Geef tegengas als jullie het gevoel hebben dat de kwaliteit van de code te weinig aandacht krijgt ten opzichte van het toevoegen van nieuwe features. Zorg ervoor dat de schattingen die je geeft aan items op de Product Backlog rekening houden met het schrijven van tests en leesbare/onderhoudbare code. Dit is niet een keuze die je moet neerleggen buiten het Development Team. Kijk ook kritisch naar de Definition of Done, en zorg dat aspecten gerelateerde aan code-kwaliteit daarin aandacht krijgen. Zo zorg je ervoor dat het voorkomen en bestrijden van technische schuld onderdeel blijft van de dialoog met de Product Eigenaar en de bredere organisatie. Een belangrijke tip is om dat wel op een empathische, pragmatische en vriendelijke manier te blijven doen.

3. Maak gebruik van code metrics om technische schuld meetbaar te maken

Metrics zijn een geweldige manier om iets dat subjectief en abstract is meer objectief en tastbaar te maken. Van discussies als 'Er is teveel technische schuld' ga je naar 'Zoveel % van de codebase is van lage kwaliteit'. Dit geeft je niet alleen meetbare doelen, het maakt verbetering ook zichtbaar. En dat werkt bijzonder motiverend. Je kunt denken aan onder andere de volgende metrics:

  • Cyclomatic complexity: Met deze metric kwantificeer je de complexiteit van classes en methods. De metric telt het aantal functionele paden in je code (if/then/else, switch/case, etc) en weegt dat ten opzichte van het aantal regels code. Hoe hoger de cyclomatische complexiteit, hoe moeilijker de code te begrijpen - en dus te onderhouden - is;
  • Code coverage: Een gebrek aan unit tests is een grote bron van technische schuld. De meeste IDEs en CI-servers kunnen het aantal regels code berekenen dat door unit tests gedekt wordt (de zogenaamde 'code coverage'). Het is zelden zinvol om te streven naar een dekking van 100%. Een betere stelregel is om eerst een goede dekkingsgraag te bereiken, en daarna te zorgen dat deze tenminste gelijkt blijft bij het toevoegen van verdere code;
  • SQALE-rating: Deze metric geeft een totaalbeeld van de kwaliteit van je code, gebaseerd op een groot aantal interne regels. De schaal gaat van A tot E, waarbij A de beste score is en E de slechtste. Veel plugins die gespecialiseerd zijn in het meten van codekwaliteit kunnen deze rating berekenen (zie ook hieronder);
  • Aantal 'Rule violtations: Deze metric berekent hoeveel regels uit een gegeven code-conventie worden gebroken in een codebase. De geschonden regels worden gegroepeerd naar prioriteit, bijvoorbeeld van 'critical' tot 'minor', zodat je ook weet waar je het beste kunt beginnen met refactoring;
  • Cost of Delay: Deze (handmatige) metric maakt zichtbaar hoeveel tijd je als team verliest door code van lage kwaliteit;
  • Bugcount: Het tellen van het aantal bugs is een simpele, maar nuttige metric. Naarmate de kwaliteit van de code afneemt, neemt het aantal bugs toe. Het monitoren van het aantal bugs - zeker na een release - is dan ook een uitstekende eerste stap;

Kortom; er zijn veel tools en metrics beschikbaar om technische schuld te kwanitificeren. Veel van deze tools zijn gebaseerd op 'static code analysis', en kunnen uitgevoerd worden vanuit IDE's of build- en integratieservers. Ter inspiratie heb ik hieronder een paar tools opgesomd (die binnen enkele minuten operationeel waren).

NDepend is een plugin die een groot aantal van de hierboven genoemde metrics ondersteunt. Bijzonder nuttig is de SQALE-rating (van A tot E), het percentage opgebouwde technische schuld en het aantal dagen dat nodig is om dit te repareren. NDepend kan ook handige heatmaps genereren waaruit je snel de classes kunt halen die vooral aandacht nodig hebben.

Gebruik je Visual Studio Professional of hoger? Dan kun je 'out of the box' gebruik maken van metrics voor cyclomatische complexiteit en een zogenaamde 'maintainability index' (van 0 tot 100).

Een andere optie is SonarQube. Dit platform integreert met allerlei CI-pipelines en IDEs, en genereert een groot aantal code metrics (inclusief de SQALE-rating):

Alhoewel deze metrics soms ruw zijn, of kort door de bocht, is dat geen reden om er niet naar te kijken. De metrics geven je wel degelijk een meetbaar, onderbouwd doel. Met enige configuratie zijn de metrics desgewenst nauwkeuriger te maken, bijvoorbeeld door bepaalde files of delen van je codebase uit te sluiten (zoals gegenereerde code of legacy code die niet gewijzigd gaat worden). Deze metrics geven mensen bovendien een beter begrip van de consequenties van technische schuld, en maakt het gemakkelijker om onderbouwde beslissingen te nemen over codekwaliteit. Development Teams die gebruik maken van dergelijke metrics tijdens (tenminste) de Sprint Review hebben betere, meer gebalanceerde discussies over technische schuld. Een groot verschil met de 'muur van onbegrip' die je vaak ziet bij teams die dit niet doen.

4. Maak technische schuld transparant op je backlog

Maak technische schuld transparant. Verstop het niet voor de Product Owner of de bredere organisatie. Heb je te maken met een bestaande codebase van 'rotte' code, identificeer dan welke verbeteringen noodzakelijk zijn, voorzie ze van schattingen en stel ze voor voor opname in de Product Backlog. Behandel ze als andere items op je Backlog; breek grotere items op in kleinere items en prioriteer ze met de Product Eigenaar. Op die manier help je de Product Eigenaar om een geinformeerde keuze te maken over het omgaan met technische schuld.

Een andere optie is om met de Product Eigenaar een bepaald percentage van de sprint te gebruiken voor het wegwerken van technische schuld. Het risico is wel dat de techhnische schuld (en wat er dan precies wordt gedaan) onzichtbaar blijft voor iedereen buiten het Development Team. Blijf ook hier vasthouden aan transparantie; maak zichtbaar wat je als team oppakt en bespreek het ook tijdens de Scrum Events.

Conclusies

Technische schuld is voor veel Development Teams een frustrerend en demotiverend onderwerp. Het sleutelwoord is transparantie. Maak gebruik van de transparante metafoor 'technische schuld' om begrijpelijk te maken wat de kosten zijn van code van lage kwaliteit. Gebruik diverse code metrics om technische schuld zichtbaar te maken in de code, en evalueer de resultaten regelmatig. Maak technische schuld tenslotte transparant op de Product Backlog. Verstop het niet voor de Product Eigenaar of de bredere organisatie.

Christiaan Verwijs
Christiaan Verwijs

Scrum Master, Trainer, Developer & founder of Agilistic