Prioritering av teknisk skuld? Testa kvalitetsbarometern!

Ska vi börja med definitionen av teknisk skuld?

För den här diskussionen räcker det med en rätt enkel definition:
Teknisk skuld = det där vi borde fixa i våra produktionssystem för att känna oss rimligt trygga med dem och för att koden inte ska bli för svår att underhålla.
Med den definitionen följer också att

• teknisk skuld är inte samma sak som buggar
• teknisk skuld är inte ny funktionalitet, hur efterlängtad den än är
• all teknisk skuld är inte lika akut att bli av med

Vad är problemen med att prioritera teknisk skuld?

Jag har pratat med många utvecklingsteam och produktägare som tyckt det varit svårt att diskutera och prioritera teknisk skuld. Det kan förstås bero på flera saker, men jag har sett några tydliga varianter:

Utvecklarna säger kanske något sådant här?

”Vi blir inte lyssnade på.”

”Det är omöjligt att förklara tekniska detaljer för någon som inte kan så mycket teknik – men ändå förväntas vi förklara vad vi vill göra och varför, medan den som inte förstod sedan ska prioritera det.”

”Vi kan inte ta ansvar för de system vi jobbar med om vi inte får göra de förbättringar vi ser som nödvändiga.”

”Det är lätt för produktägaren att säga nej till att jobba bort teknisk skuld,
det är ju inte hen som måste fixa akuta problem i systemen på kvällar och helger.”

Produktägaren å andra sidan, kanske tycker att

”Teamet vill ju alltid göra detaljförbättringar, trots att saker redan fungerar ok.”

”Om vi bara gör förbättringar av det som redan finns så kommer vi aldrig i mål.”

”Det är svårt att försöka prioritera saker som jag inte förstår mig på – även om jag skulle vilja – och teamets tekniska förklaringar hjälper inte.”

…men problemet är egentligen något annat

Det finns säkert både allvarliga och mindre allvarliga problem i systemen.
Att teamet vill fixa de problemen tyder på ansvarstagande, vilket såklart är bra.

Det kan säkert också uppstå problem om vi inte får ut X i release Y.
Att produktägaren driver på för ny funktionalitet ingår i jobbet, så det är också bra.

Problemet här ligger faktiskt någon annan stans, nämligen i att teamet och produktägaren hindras av diskussionen i sig , vilket kan göra att saker går långsamt, kvaliteten blir lägre än nödvändigt och att kunderna får vänta i onödan på ny funktionalitet – vilket tom kan påverka intäkterna. Allt detta alltså trots att både produktägaren och teamet tar ansvar och vill göra bra saker.

Det är alltså diskussionen i sig som behöver bli mer produktiv, sakligare och trevligare.
Så, vad kan vi göra för att teamet och produktägaren ska kunna jobba tillsammans i en diskussion istället för att argumentera mot varandra som om de var på olika lag?

Här kan man prova att skapa en kvalitetsbarometer som man sedan ändrar, förbättrar och gör till sin egen.

Så vad är en kvalitetsbarometer?

En kvalitetsbarometer är ett verktyg som gör det möjligt att diskutera kodkvalitet och kodförbättringar med icke-tekniskt språk och sedan göra en sammantagen bedömning av kodkvalitet med lite mer distans.

Här är några exempel på faktorer som en kvalitetsbarometer kan ta upp och ge utrymme för att diskutera i en viss del av koden, låt oss kalla den X:

• Hur ofta uppstår problem med kod X?
• …och hur mycket påverkas kunderna av det?
• …och hur ofta påverkas kunderna av det?
• …och hur mycket påverkas våra utvecklare/testare/Ops:are av det?
• …och hur ofta påverkas våra utvecklare/testare/Ops:are av det?
• Hur ofta behöver teamet jobba i kod X?
• Hur svårt är det att fullständigt förstå kod X?
• Hur snabbt/långsamt går utveckling i kod X?
• Hur riskabelt är det att utveckla (ändra) i kod X?
• Hur länge ska kod X leva? (istället för att läggas ned eller ersättas).

…och hur fungerar den?

Alla kvalitetsbarometrar bör anpassas till den egna organisationen och situtationen; till och med till de egna värderingarna. Därför får vi nöja oss med ett generellt exempel här:

Förberedelser

1. Teamet och deras PO börjar med att diskutera fram vika frågor/bedömningskriterier som känns vettiga att använda, och som gör att ingen känner att någon aspekt helt missas. Det här hör till det som sedan kan ändras i iterationer.
2. För varje fråga/bedömningskriterie bestämmer teamet + PO en enkel skala, till exempel ”Ofta – Ibland – Aldrig(nästan)”, ”Svårt – Sådär – Lätt” eller
   ”Mycket – Till viss del – Inte alls (i stort sett)”
3. Teamet och deras PO enas om hur de olika aspekterna ska påverka en sammantagen bedömning och därmed hur en enkel formel för att beräkna det kan se ut. Diskussionen kring det kan säkert bli livlig, men om teamet är någorlunda välfungerande bör den inte vara omöjlig att komma i mål med.(Här är det viktigt att komma ihåg att den matematiska precisionen är mycket låg eftersom allt började med övervägande subjektiva bedömningar. Resultatet kan vara användbart ändå; vi får hjälp att göra gemensamma bedömningar och sedan jämföra dem med varandra.)

Hur kan vi använda det här i vardagligt arbete?

1. Diskutera bedömningarna för varje del av koden (kan behöva bli flera diskussioner)
2. Använd den skapade formeln för att räkna ut en poängsumma per del av koden.
   I det här exemplet skulle minsta möjliga summa vara Qc = 1*((1*1)+(1*1))*1*1*1 = 2
   och högsta möjliga summa skulle vara Qc = 3*((3*3)+(3*3))*3*3*3 = 1458.
   Tabellen här ovanför skulle resultera i: Qc=2*((2*2)+(1*3))*2*1*2 = 56.
3. Visualisera summorna för varje del av koden, till exempel så här:
   
4. Diskutera hela resultatet och för in det i övrig prioritering och planering.

Kommentarer till formeln

1. Formelns utseende bör baseras på de egna åsikterna och värderingarna.
   Bilden visar alltså bara ett exempel.
2. Formeln kan anpassas för att värdera olika delar annorlunda.
   Till exempel kan vi ändra till ”…*2D*…” om vi värderar lättförståelig kod extra högt eller ”…+E…” om vi inte vill bry oss så mycket om kodens förväntade livstid.

Hur kan vi arbeta vidare med kvalitetsbarometern?

Jag vill rekommendera några saker för att det här ska gå rimligt lätt att använda:

• Som alltid bör en PO vara särskilt utsedd, engagerad och insatt – och ha tid.
• Kvalitetsbaromentern bör uppdateras ofta, allteftersom saker händer och team+PO
  lär sig saker och får erfarenhet.
• Alla bör försöka strunta i prestigen och tidigare, mindre lyckade diskussioner.
  Det kräver i sin tur trygga team och bra ledarskap.
• Teamet och PO:n bör visa varandra att det spelar roll vad som sägs och beslutas och att vi vill hjälpas åt; att det inte handlar om politik eller sätt att hantera varandra.
  Konkreta sätt att göra det kan vara att PO prioriterar upp saker som får höga poäng i barometern så att teamet ser att deras kunnande och input verkligen tas på allvar, men teamet ser till att inte fastna i detaljer eller påstå att allt är lika viktigt.

Inte min idé från början

Det är ett antal år sedan jag såg utkastet till en kvalitetsbarometer första gången och jag vet inte vem som då hade första idé-embryot. Det här är alltså inte min idé från början, jag har bara utvecklat den, lagt till visualisering, beräkningar och skalor och sedan tagit den vidare i diskussion med fler team. Eftersom jag inte vet vems idé det var från början  så kan jag bara säga ”Tack!” till mina fantastiska team och alla andra intresserade som bidragit. Tack!

Sammanfattning

Ofta är det inte de konkreta problemställningarna som utgör de största hindren i vårt dagliga arbete. Istället är det ofta det mänskliga; hur vi agerar och pratar med varandra till exempel.
Kvalitetsbarometern kan vara ett sätt att få till trevligare och mer strukturerade diskussioner.

…och en sak till: Om någon tycker att det här påminner om enkel riskhantering med bedömningar av sannolikhet och påverkan och riskgrafer så håller jag med.

Lycka till!