Nästan alla påstår sig vara agila. Vissa "på sitt sätt", andra mer formellt som en del av ett ramverk. Från små nystartade företag till stora bilförsäljare, från utvecklingsgrupper till HR, att inte vara agil är motsvarigheten till att erkänna att du hatar hundvalpar eller något lika normbrytande.
Även om ett agilt arbetssätt fungerar som ett universalmedel för alla problem, handlar den här artikeln inte om att räkna upp de olika sätten det har slaktats på. Istället kommer jag fokusera på varför det är svårt att uppnå vad agil utveckling lovar: Ett värde som levereras till kunder iterativt för att upprätthålla korta feedbackcykler. Detta underlättar snabb respons i samband med förändringar i omgivningen och bidrar med maximerad anpassning till de senaste affärsbehoven.
Varför misslyckas dina agila projekt? Är det för att du inte följer SCRUM, SAFe, LeSS eller <infoga metodik här> religiöst nog? Är det så att toppledningen bara följer en vattenfallsmodell med agila inslag istället för att adoptera tankesätten?
Möjligen, men du är också belastad med vikten av teknisk skuld.
Teknisk skuld är en metafor som myntats av Ward Cunningham 1992 och beskriver aktiviteter du inte utför i nuläget, men som sannolikt kommer att skapa problem längs. För att sätta detta i perspektiv; hur kan du vara agil och leverera värde snabbt när alltför stora ändringar krävs för varje ny funktion på grund av suboptimal arkitektur? Eller när upprepade buggar förstör din användarupplevelse och mekanismen för att säkerställa leveranser av hög kvalitet är alldeles för besvärlig? Du kan helt enkelt inte vara agil när du plågas av teknisk skuld.
Alves, Nicolli SR, et al. (2014) har i sitt arbete med titeln "Towards an ontology of terms on technical debt" identifierat 13 typer av teknisk skuld i mjukvaruprojekt. Några av de vanligare inkluderar:
Arkitektur- & designskuld
Hög koppling, ingen åtskillnad av oro, brist på modularitet, användning av antimönster
Kodskuld
Kod luktar, oläslig och mycket komplex kod
Test & automatiseringsskuld
Låg kodtäckning, manuell testning och distribution
Folkskuld
Knapp och koncentrerad expertis, brist på delad kunskap
Oavsett vilket agila ramverk du väljer så är teknisk skuld oundvikligt. Det agila ramverket illustrerar hur du organiserar ditt projekt, fördelar rollerna och definierar release-processen, men kommer inte göra de avgörande valen för dig när du hamnar i skuld.
Hur kan du då skydda ditt projekt från att bli lamslagen av teknisk skuld?
Teknisk skuld ackumuleras av val som, medvetet eller inte, gynnar kortfristiga intäkter framför negativa konsekvenser i framtiden. Därför bör du:
Erkänna teknisk skuld som en av de främsta faktorerna som hindrar din effektivitet, tid till marknad och innovation
Återbetala teknisk skuld genom att förse dina utvecklare med nödvändiga resurser
Lär projektmedlemmarna att urskilja beslut som ökar teknisk skuld
De två förstnämnda handlar om strategi, kultur och i slutändan insikten att ju längre du undviker handling, desto närmare kommer du förödelse. Med det senare kan Edument hjälpa till med våra begåvade konsulter och våra kurser om olika programmeringsspråk, mjukvaruarkitektur, testdriven utveckling, och Git.
