Technical debt
Discussion on all act at xebia.com around 2012-06-30:
- Rik de Groot:
- Zet de technical debt op de backlog. Zo weet de product owner altijd waaruit hij kan kiezen en het team kan hem beïnvloeden/overtuigen dat bepaalde items randvoorwaardelijk zijn.
- Er zijn eigenlijk altijd 3 categorien bij backlog items:
- waarde toevoegend;
- noodzakelijk en indirect waarde toevoegend; en
- mogelijk waarde toevoegend.
Vaak zijn de technical debt items van de categorie 2 of 3 die wat mij betreft altijd op de backlog staan.
- Theo Gerrits:
- Als technical debt oplossen waarde toevoegt aan het product, dan is het dus iets van belang voor de product owner. Zo niet, dan moet je er al helemaal geen aandacht aan besteden.
- Serge Beaumont:
- For impediments, a.k.a. the backlog of pain, I use the template: symptom caused by root cause leads to real problem
- Laurens Bonnema:
- Je moet kunnen uitleggen waarom een bepaalde user story meer werk oplevert dan je op het eerste gezicht zou denken. Dat kan het moeten wegwerken van, al dan niet net ontdekte, tech debt zijn. Maar bijvoorbeeld ook het binnen de lijntjes moeten kleuren van een security afdeling of OTAP omgeving.
- Als technical debt al op het bord komt zonder integraal onderdeel te zijn van één of meer user stories, dan zou ik het als impediment opnemen, niet als user story.
- Maurits Rijk:
- Waar ik moeite mee heb is dat dit 'probleem' wordt opgelost door dan maar de PO aan te wijzen als de wijze oude man/vrouw die wel bepaalt of dat nu verstandig is of niet. Ik wil juist dat die verantwoordelijkheid door het team wordt genomen! Dus graag een zodanige teamsamenstelling dat er op z'n minst 1 persoon tussen zit die de juiste vragen stelt. Dus ook liever geen project manager/Scrum Master die alles afwijst onder de naam 'koper poetsen'.
… Dat is inderdaad 1 van mijn bezwaren. Voordat je het weet doe je dan ook voor het gemak nog maar je storiepoints gelijk aan dagen (ja, ik heb het zien gebeuren!) en dan wordt je velocity wel heel erg constant en voorspelbaar ;)
Ik wil een opbouwende technical debt graag heel concreet zien als een afnemende velocity.
Overigens zie ik (afgezien van legacy code) technical debt meestal ontstaan door druk van een PO ("deze deadline is absoluut belangrijk" en dat soort zinnen) waardoor er geleidelijk allerlei shortcuts in de code sluipen. Best is natuurlijk (zoals Pieter al aangeeft) om dat te voorkomen, maar een hele geleidelijke opbouw kun je nooit helemaal voorkomen is mijn ervaring. Dan moet je als team (die gaan namelijk over het 'hoe') besluiten om je snelheid voor 1 of meerdere sprints nog wat verder te verlagen om deze situatie recht te trekken. De PO heeft dan wel recht op uitleg en mag daar uiteraard vragen over stellen, maar verantwoordelijkheid ligt bij het team. Anders wordt 'zelfsturend' wel een heel erg hol begrip.
Het meest extreme geval is hele sprint gebruiken voor wegwerken technical debt, maar daar ben ik ook geen voorstander van.
Ik vind dit wel een hele zinvolle discussie. Zelfs over iets 'eenvoudigs' als technical debt hebben we toch verschillende inzichten en meningen. Overigens moet ik daaraan toevoegen dat in deze mijn mening wel de enige juiste is ;)
…
In onze standard slidedeck voor de Scrum Training zit een slide waar ik het fundamenteel niet mee eens ben: de slide waarin staat dat *alle* werk op de backlog terecht komt, zodat de PO kan prioriteren. Dat geldt in dus ook voor bijvoorbeeld technical debt.
Ik kan een groot aantal redenen bedenken waarom dat een absoluut dom idee is en eigenlijk geen enkele wat er het voordeel van zou kunnen zijn, maar wellicht zie ik iets over het hoofd. Kan iemand dat toelichten zodat ik die slide volgende keer zonder tegenzin kan presenteren? Persoonlijk vind ik dat er alleen maar functionele user stories op horen en verder helemaal niks.
- Richard Schaaf:
k weet niet of ik hier nu een + of een - aan moet geven. Ik ben het er namelijk mee eens, maar niet met de conclusie.....
We gaan allemaal uit van 2 denk ik. Maar het kan zijn dat: - je er in de loop van de tijd achterkomt dat je in de architectuur dingen wilt wijzigen - dat er een nieuw framework is dat erg goed toepasbaar is en dat voordelen op gaat leveren op termijn - pakket X zijn support op versie Y laat aflopen - ....
In al die gevallen was je code totaal "clean" bij het opleveren van de sprint, en voldeed dus aan de DoD. Anders was het namelijk niet af.
Maar..... later blijkt dus dat je iets wilt doen; de technical debt ontstaat dus. In alle gevallen die ik hier geef zal het verbeteren geen functioneel verschil opleveren, maar je wilt het wel doen. Wat doe je dan? De debt is er namelijk toch, en niet omdat je in eerste instantie je werk niet had gedaan.
Naar mijn mening is het in alle gevallen die ik hier geef zo dat het juist de PO is die de beslissing moet nemen of hij/zij daar geld aan uit wil geven. De architectuur aanpassen is leuk, maar wat levert het op? Kan ik daarmee bepaalde backlog items minder punten toekennen? Gaat de velocity omhoog? En wat als ik het niet doe, wat zijn dan de gevolgen. Als je dit niet aan kunt geven is mijn stelling dat je de architectuur dus niet moet aanpassen.
En dat geldt ook voor nieuwe frameworks, nieuwe versies van pakket X, etc. Ik vind het dus wel degelijk een beslissing voor de PO om het wel of niet op te lossen. Ik heb te vaak meegemaakt dat een team het ene framework na het andere wilde uitrollen, gewoon omdat het mooier was, zonder ook maar enige waarde aan te kunnen geven. Dat kan wat mij betreft dus echt niet.
Dus: mijn stelling is dat - als je technical debt veroorzaakt binnen een sprint dan doe je iets fout (zou niet mogen) - als technical debt ontstaat, dan moet je aan de PO kunnen aangeven waarom die opgelost moet worden, is het aan de PO om te beslissen en zet je het oplossen op de backlog.
Dus ik ben het eens met Pieter dat het deel moet zijn van de DoD, maar daar los je niet alles mee op....
…
Als er technical debt is dan moet er een reden zijn om het op te lossen, en die kun je dan voorleggen aan de PO. Kost het hem extra geld voor onderhoud? Gaat de velocity omhoog als je het oplost? Als je er geen waarde aan kunt hechten dan moet je het ook niet oplossen. Bovendien: alleen het feit al dat je weet dat je de PO uitleg moet geven als je technical debt veroorzaakt helpt om die te voorkomen.
Hoe wil je het anders doen? "Sorry PO, maar we gaan deze sprint maar de helft van de velocity halen, want we gaan ook wat technical debt oplossen"? Als PO zou ik dan meteen 2 vragen stellen: "waarom is die debt er eigenlijk", en "wat levert het me op om het op te lossen".
Dus ja: alle werk op de backlog, dat maakt het transparant. Of je het dan nog een User Story kan noemen, dat denk ik niet, maar het is wel een backlog item waarover de PO beslist.
En zoals Erik zegt: wat zou het nadeel zijn? Behalve dat er niet-functionele dingen op de backlog staan? Die staan er toch vaker op? Wat zou je bijvoorbeeld doen als de PO aankomt met nieuwe niet-functionele requirements halverwege, dus zaken die niets functioneel wijzigen, maar wel gedaan moeten worden. Dit is geen technical debt, maar ook niet functioneel; dus dat mag dan ook niet op de backlog?
Dus: wel op de backlog, maar niet als User Story wat mij betreft.
- Pieter Rijken
In het verleden heb ik eens een project gehad dat startte met veel technical debt.
Dit hebben we toen opgelost door op de DoD o.a. te zetten:
- delta in #PMD violations < 0, - delta code coverage > 0, - distance steeds dichter bij 1, - delta McCabe < 0
Sterker nog: dit was als thesholds in de continuous integration omgeving ingebouwd. De bouw en checkin werden automatisch afgekeurd.......het (echte) stoplicht aan het plafond sprong dan op 'geel': testen geslaagd maar kwaliteit niet gehaald.
Hierdoor ging de technical debt geleidelijk omlaag.
Andere knuppel......ik ben er voor dat als je technical debt op de PBL zet het niet mee te laten tellen in de velocity (het systeem wordt er niet bruikbaarder van voor de PO). Als technical debt omlaag gaat, krijg je meer tijd om meer features te bouwen en gaat je velocity juist omhoog. Je wordt beter!
Als je 'technical debt' user stories meetelt in velocity, is het moeilijker aan de velocity te zien dat je beter wordt.
…
Dan maar de knuppel in het hoenderhok....
Er worden, denk ik, twee dingen door elkaar gehaald: 1) je hebt (veel) legacy code en begint met een behoorlijke portie technical debt, 2) je hebt schone code met geen technical debt.
Ik ga ervan uit dat Maurits situatie 2) bedoelde. In dat geval houd je je code schoon bij iedere user story (DoD ipv PBL). In situatie 1) kan ik het mij nog voorstellen; dat je een beperkt aantal sprints een beperkte capaciteit reserveert om technical debt tot een acceptabel nivo te brengen.
Nadeel vind ik dat als technical debt op de PBL staat de product owner er voor kan kiezen technical debt 'items' niet te doen. Hiermee bepaalt de PO deels het 'hoe'.
Als je 'technical debt' op de DoD zet (ja; dat kan; bijv. 'alle code is fit for change') is het ook heel transparant. Door aan het begin van de sprint taken te maken met bijv. technical debt er expliciet in, voorkom je bovendien dat de PO verrast wordt tijdens de sprint; het staat immers de hele sprint op het bord.
Tuurlijk moet je het als team uit kunnen leggen dat het nodig is. Als het team het nodig vindt, is het nodig.
Enne.....technical heeft geen business value....als het dat wel heeft, kun je het ook als user story formuleren.
…
Functioneel dan in de zin dat het (=user story) een waarneembare verandering in (systeem)gedrag is (dit is dus inclusief zogenaamde non-functionals, bugs, ...).
Ik leg ook altijd uit bij teams dat refactoring/technical debt in de sprint thuishoort. Anders is de story
niet af. Zelf houd ik ook niet van 'speciale refactor' sprints.
Voordeel vind ik verder dat het heel duidelijk is naar de teams/PO toe.
- Erik van der Velde
Ik kan een groot aantal redenen bedenken waarom het een GOED idee is en eigenlijk bijna geen nadelen. Of een nadeel zou moeten zijn dat je meer met de PO moet praten.
Ik vind het een groot voordeel van *al* het werk op de backlog heb staan: - Alles waar je in een sprint aan werkt komt van de PBL - Er dus geen dingen in de sprint gedaan worden die niet op de PBL staan - Voortgang van project beter te voorspellen is, doordat "totaal backlog / velocity (trend) = aantal sprints te gaan" - Transparantie: Je moet de PO uitleggen waarom die "niet echte userstories" nodig zijn , want het gaat hem geld kosten - Je scrum team moet, helaas, soms werken aan technische zaken die voor zowel Scrumteam als PO als niet belangrijk lijken, maar in zaken als b.v. een database update, omdat anders je support in productie afloopt, gaat wel tijd van je team zitten en ik zou dit altijd expliciet willen terugzien in PBL. - Geen verrassingen bij de PO in de sprint, dat er aan dingen gewerkt word waar hij/zij niet van op de hoogte is. - Er geen "vertroebeling" van je velocity ontstaat: "Tja, die spint hebben we maar xx punten gedaan omdat we nog wat technische zaken moesten regelen..."