Smidig 2009

Intro

Scrum baserer seg på at alle oppgaver kan settes inn i produktkøen, prioriteres, estimeres og plukkes av et team. Gamle synder og teknisk gjeld har ofte tendens til å bli nedprioritert når sparekniven tas frem, fordi kunden vil alltid mene at ny funksjonalitet er viktigst. Når neste sprint skal plukkes, dukker det igjen opp nye (enda viktigere) funksjonelle oppgaver. Til slutt forsvinner de tekniske oppgavene ned på gulvet.

Jeg mener at vi ikke bør prøve å snike inn skitten teknisk gjeld blandt blank og finpusset ny funksjonalitet, men heller håndterer det i en egen tråd, på en egen tavle. Istedenfor story points bruker vi en risikomatrise: Hvor galt _kan_ det gå hvis problemet forblir uløst? Hvor sannsynlig er det at det verst tenkelige skjer? Hvis det skjer, har vi tid og råd til rekonvalesens?

Istedenfor å forholde seg til sprinter, bør vi kontinuerlig vurdere nye trusler og (ikke minst) gamle trusler, gjerne flere ganger per sprint. Teknisk gjeld forrentes akkurat som pengegjeld. Ikke glem å regne med kostnaden av å utsette en forbedring eller opprydning.

Prøv å sette tall på hvor mange timer tekniske renter koster hver sprint. Følg med på om kostnaden vokser. Snakk med folk. Få andre til å anslå kostnaden. Identifiser hvilke problemer som vokser i omfang. De må håndteres - heller før enn siden. Unngå å bli den frosken som koker langsomt i gryta.

Hvor oppstår teknisk gjeld?
- integrasjonspunkter
- domenemodell
- (prorpitære) patterns
- initialiseringskode
- plugins og utils-kode
- rammeverk
- ...

Felles for alle disse punktene: Det er flaskehalser i prosjektet - funker ikke rammeverket ditt, så sitter hele prosjektet på gjerdet og venter på at det skal komme på plass. Det legger press på deg, og gjør deg predisponert for å kutte noen svinger.

Slik gjør vi det

Vi prøver ut en løsning hvor tekniske oppgaver kategoriseres som enten planlagte eller ad hoc.

"Planlagte oppgaver" er typisk langsiktige endringer: Oppgradering av grensesnitt, oppgradere biblioteker og programvare, opprydning på tvers av kode, innføre nye regler med tilbakevirkende kraft .. Alle disse tingene håndteres som PK'er, og man kan velge å ta kostnaden ved å ikke løse dem. De er også "teknisk gjeld", men gjelden er synlig.

Ad hoc er ting som plutselig oppstår, og det er disse tingene som lett blir gjemt og glemt i scrum. Raske og skitne fikser for å få landet en oppgave, fikse litt på et script, legge til nye brukere, nytt prosjekt i hudson, refaktorere noen maven-moduler, rydde vekk redundans i deployment descriptorer.. Det er ting som før eller siden bør gjøres, og det er alltid veldig mange av dem. Men de er så små at det tar mindre tid å fikse dem enn å få dem prioritert i en sprint.

Vi har en egen tavle til disse, og et eget "teknisk lag" hvor 4 personer er allokert 20% - fordelt utover uken, slik at det alltid er noen som har tid til å fikse og redde og hjelpe og trøste. Hvis det ikke er noe akutt, kan man angripe gamle lapper.

Konklusjon
I praksis blir dette som å kjøre kanban inni scrum, med prosjektet som kunde.