Teknisk skuld eller “cost of inaction (COI)” är kostnaden för att INTE göra någonting.
Att bygga och leverera nya features som skapar affärsnytta är oftast roligare och värderas ofta högre än att städa upp och förbättra saker som redan har levererats. Det innebär dock att “skulden” kommer att öka över tid och efterhand kommer det påverka teamets velocitet och förmåga att leverera ny funktionalitet. I värsta fall kommer det innebära att både processer och system kommer att stagnera och det blir alltmer komplext att göra förändringar vilket tvingar fram förändringar. Det man kan vara säker på är att detta inte kommer att ske vid ett lämpligt tillfälle, tvärtom uppenbarar det sig oftast vid det värsta tänkbara tillfället.
Att återta kontrollen
Första steget är att lista alla nuvarande problem och möjligheter, analysera dem och identifiera vilka som kommer kosta dig mest om du inte gör någonting åt dem.
Detta skulle till exempel kunna vara_
- Refakturera den nuvarande koden (eller bygga om “Proof of Concept” och MVP’s till mer robusta lösningar)
- Uppdatera testfall
- Uppdatera dokumentationen
- Förbättra processer
- Implementera eller öka automatiserade tester
- Ta bort “död kod”
- Öka prestanda
- Förbättra stabilitet
- Förbättra eller minska beroenden mellan funktioner
- Öka feltoleransen
Nästa steg är att göra dina COI-items synliga genom att lägga till dem i din backlog
- Skapa en etikett så att du enkelt kan övervaka tillväxten av COI-items i din backlog
- Prioritera baserat på effort och severity
- Använd data som input till dina retrospektiv och “backlog grooming” sessioner
- Prioritera dina COI-items mot utveckling av ny funktionalitet för att få en bra balans
- Analysera din process för att för att undvika nya COI-items
Låt konversationen om COI bli en naturlig del av din process och ha en väl grundad diskussion baserat på det data som du har samlat in.
