Kwaliteit door paardenbloemen plukken

Je kent het wel. Na een paar maanden is je mooie grasveld ineens veranderd in een zee van paardenbloemen. En wat je ook doet, het woekert maar voort. Zo gaat het ook met kwaliteit in software.

In het begin gaat alles snel en makkelijk in het ontwikkelteam en is iedereen blij. Maar al snel duurt het steeds langer voordat nieuwe functionaliteiten opgeleverd worden en begint het te jeuken. Er is “onkruid” gaan woekeren, en als je lang wacht krijg je het niet meer weg. Uiteindelijk roepen de ontwikkelaars dat de “Technical Debt” te groot is geworden en dingen “herbouwd” moeten worden. Oftewel: afgraven en nieuwe graszoden leggen. Maar lost dit het probleem wel op?

Lees hieronder wat je hier aan kunt doen!

 

Kwaliteit is WEL gratis

In een grasveld komt na een paar weken het eerste onkruid al weer boven. Ontwikkelaars geven ook aan dat ze al snel afgeremd worden. Niet na maanden of een jaar, nee na een paar weken gaat de opgebouwde “Technical Debt” al ten koste van de ontwikkelsnelheid [2]!

Het is dus niet zo als in het dagelijks leven. Daar hebben dure spullen meestal een betere kwaliteit. In softwareontwikkeling ben je juist minder geld kwijt als je vanaf het begin tijd neemt voor kwaliteit. Kwaliteit is een “must” om met voldoende snelheid op te blijven leveren en niet de volgende sprint (of die erna) al tijd kwijt te zijn aan onkruid dat in de weg zit. Het geeft een scrumteam dus direct business waarde.
Kwaliteit is in feite gratis, want als je het niet doet, kost het je al heeuuul snel meer geld.

 

En hoe dan?

Ik kan hier nu allerlei tips en tooling gaan noemen. Maar dat is eigenlijk niet nodig: in mijn ervaring weten de scrumteams best zelf heel goed hoe ze onkruid (Technical Debt) kunnen voorkomen. En hoe ze bestaand onkruid dat in de weg zit het makkelijkst kunnen verminderen.

De oplossing is om teams ruimte te geven dit te gaan DOEN door ruimte te geven: [bctt tweet=”Behoud opleversnelheid door scrumteams te laten BEGINNEN met 1/4 van de sprint te vullen met Technical Debt stories. En daarna de business stories in te plannen” via=”no”]

Bij de scrumteams binnen Alliander bereiken we hier sinds het begin van onze Digitaliseringsreis, 2017, goede resultaten mee. In het kwart van sprint wordt er onkruid gewied, terugkerende handmatige klusjes geautomatiseerd, en andere verbeteringen doorgevoerd. Zoals het gaan werken volgens Test Driven Development en het inrichten van testautomatisering, Continuous Delivery en kwaliteitstools zoals Sonarcloud, security scanners (Github CVE security scanning, XRay container security scanning, Sonarcloud security hotspots), Dependabot, Gatling, etc.

 

The Google way

Bij Google worden teams zelfs afgerekend op het voldoende tijd besteden aan het voorkomen en oplossen van Technical Debt [3]. Gebeurt dat niet, dan wordt een team verboden om functionaliteiten op te leveren (!) totdat die tijd ingehaald is. Zo voorkomt Google dat opleverdruk de kwaliteit naar beneden haalt.

 

Paardenbloemen plukken is afwassen

In het dagelijks leven kan je niet koken zonder het keukenaanrecht vies te maken. Maar als je niet direct schoonmaakt, gaan zaken vastkoeken en kun je het volgende gerecht niet maken. Of als je niet af en toe paardenbloemen uit je grasveld trekt, dan gaat het binnen een paar weken woekeren en ben je als snel meer tijd kwijt. Toch voelt het schoonmaken en onkruid wieden als vervelend werk.
Bij software ontwikkeling is dit niet zo: Ontwikkelaars zien kwaliteit niet als corvee, maar als vakmanschap. Het voorkomt gezucht en gesteun bij het realiseren van stories in volgende sprints.

 

Technical Debt voorkomen? Gewoon doen!

Kortom: Als je als Product Owner of scrumteam goed op de centen let en waarde wil blijven leveren, dan reserveer je minstens een kwart van elke sprint voor “paardenbloemen stories”.

Bij de digitaliseringsteams van Alliander komt een kwart van het budget uit IT-(beheer)budgetten ipv business budgetten. Dit kwart kan het ontwikkelteam zelf besteden (per sprint), en valt buiten zeggenschap van de Product Owner.

 

Update mei 2022

In de praktijk werken we met Technical Stories ipv Technical Debt. Dat is wat duidelijker en er past ook wat meer onder:

• Oplossen shortcuts ontstaan onder opleverdruk (=Technical Debt)
• Noodzakelijk technisch onderhoud (upgrades), bv ivm security
• Vervangen van niet meer gesupporte zaken
• Automatiseren van handwerk van developers (mits geen bewuste business keuze destijds)

 

Bronnen:

1. Tech Debt, mei 2019, Martin fowler 
2. Is High Quality Software Worth the Cost, mei 2019, Martin fowler, 
3. Google’s methode: Production Ready Microservices, dec 2016, ISBN 9781491965979