Att balansera nyutveckling mot teknisk skuld – fem vanliga fallgropar

Vi listar fem vanliga fallgropar och hur du som produktägare kan undvika dem.

1. Du ignorerar den tekniska skulden.
2. Du ger verksamheten för generösa förväntningar av mängden nyutveckling.
3. Inblandade produktteam samarbetar inte kring den tekniska skulden.
4. Du regressionstestar inte tillräckligt.
5. Du har en för komplex arkitektur som göder den tekniska skulden.

1. Du ignorerar den tekniska skulden

För att inte hamna i en situation där din, eller andras produkter, blir omöjlig att underhålla och nyutveckla till behöver du veta vad en teknisk skuld är samt vilka faktorer som driver den. En teknisk skuld är enkelt förklarat den mängd buggar, incidenter, datakvalitetsproblem och bristfällig UX som under tid byggs upp till följd av nyutveckling.

Den tekniska skulden är naturligtvis olika stor beroende på typ av produkt men generellt så drivs teknisk skuld av:

• Produktens ålder.
• Antal beroenden och integrationer mot andra produkter.

• Mängden nyutveckling.
• Kvalitet på testning.

En äldre produkt med ett fyrtiotal integrationer och många anpassningar har alltså en klart större risk för en stor teknisk skuld jämfört med en ny produkt med få, standardiserade kopplingar till andra produkter och tjänster. Det bästa du kan göra är att utifrån en riskanalys bedöma hur mycket du behöver arbeta med din tekniska skuld i varje Product Increment. Riskanalysen kan utgå ifrån historiska incidenter och resultat av regressionstestning.

2. Du ger verksamheten för generösa förväntningar av mängden nyutveckling

Verksamheten älskar ny funktionalitet och helst skall den vara implementerad igår. Förväntningarna är att allt skall fungera utan incidenter och problem och om det händer något är det dig de gnäller på. Känns det igen?

Det enda sättet att få en långsiktig lösning är att vara 100% transparant. Visa för dina intressenter vilka incidenter som inträffar, vilka komplexa beroende till andra system som skapas när vi implementerar funktionalitet X och den negativa effekten på prestanda av funktionalitet Y. Först då kan du hålla i en PI Planning där du får förståelse varför teamet skall jobba med att beta av den tekniska skulden i stället för 100% nyutveckling.

3. Inblandade produktteam samarbetar inte kring den tekniska skulden

Vår erfarenhet är att produktteam är bättre på att samarbeta kring ny funktionalitet än att tillsammans förhindra att den tekniska skulden ökar. När det väl är dags att jobba av skulden är beteendet ofta ännu mer protektionistisk med handpekande och ovilja att ta ansvar.

För att förhindra att detta händer är en samsyn så klart viktig, speciellt under PI planning. Det är också viktigt att teammedlemmar är medvetna om vad andra team jobbar med samt kan dra slutsatser av hur deras implementationer påverkar andra produktteam. Här har arkitekter en viktig roll men även produktägare som behöver kommunicera planerade förändringar med andra produktägare.

Om du hamnar i en situation där den tekniska skulden blivit för stor kan det vara en idé att ta in en resurs som bara jobbar med att koordinera initiativ mellan olika produktteam.

4. Du regressionstestar inte tillräckligt

Regressionstestning är testning av produktens standardfunktioner för att säkerställa att dessa inte påverkats, avsiktligt eller oavsiktligt, av ny funktionalitet. Denna typ av testning kan helt eller delvis automatiseras för att inte driva för mycket resurser. Regressionstestning är extra värdefullt för att inte bygga upp en teknisk skuld då en effektiv sådan tidigt kan hitta problem. Gör du inte regressionstestning? Börja med det med en gång!

Ett annat problem kan vara att testning görs för grunt eller översiktligt, vilket ger en falsk trygghet. I komplexa miljöer kan det vara värt att satsa resurser på att bygga upp automatiserade tester som exempelvis jämför stora mängder databasposter mellan olika system eller komplicerade transaktionsflöden.

5. Du har en för komplex arkitektur som göder den tekniska skulden

Den tekniska skuldens bästa vän är många integrationer som gärna skall vara beroende av varandra, allra helst med komplexa tidsberoenden där några transaktioner är synkrona och några asynkrona. Lägg till valideringar som görs på olika sätt i olika system, batchjobb som verksamheten tillåts köra utan att kommunicera med produktteam, prestandaproblem som får vissa integrationer att tillfälligt gå ner och fellistor som ignoreras så har du en miljö där varken användare eller utvecklare kommer vara särskilt glada.

Det här är tyvärr vardag för många, speciellt för de som jobbar i stora verksamheter med många legacysystem. Här har arkitekter en nyckelroll där kompetens och, kanske lika viktigt, integritet måste få styra. Det måste vara ok att säga nej till för komplexa lösningar med följden att det tar längre tid att implementera.

Arkitekten har också en nyckelroll vid införandet av helt nya system. Val av plattform kommer sätta agendan för många år framöver.

Vill du ha hjälp med din tekniska skuld? Biner har konsulter med långvarig erfarenhet av arkitektur, att bygga produktteam och definiera teststrategier. Vi har också coacher som får produktteam att samarbeta bättre.