Agile værktøjer kan forhindre agilitet

I mit blogindlæg Drop knæfaldet for det agile omtaler jeg afslutningsvis, at lavpraktik, sund fornuft, just-do-it-principper og viljen til at nå i mål er væsentlige, når vi taler om at få agile projekter til at lykkes. Jeg er fra flere sider blevet opfordret til at uddybe dette, og det gør jeg selvfølgelig gerne.

Jeg har med afsæt i mange års erfaring med agile projekter oplevet, at en for ensidig fokusering på nogle agile værktøjer i visse tilfælde kan medføre en tilstand, der ender med at mindske eller helt forhindre agilitet. Ja, hvem havde set det komme!

Eksempelvis er den agile udviklingsmetode SCRUM ganske udbredt ved udvikling af software. SCRUM udmærker sig ved, at man typisk vælger, at et team arbejder i 14-dages sprints. Idéen er, at teamet forpligter sig til en bestemt mængde arbejde, som teamet selv har været med til at estimere, og i de 14 dage er teamet ”fredet” for omverdenen.

Alt sammen med den gode hensigt, at teamet skal præstere fremdrift og levere fungerende software. ”Fredningen” er med til at beskytte teamet imod alt dét, der kommer flyvende ind fra højre, og som ofte stjæler tiden fra dét, som teamet ellers skulle have arbejdet med. Ofte med det resultat, at teamet ikke når deres deadlines.

Ceremonier og artefakter
SCRUM er skruet sådan sammen, at hvert sprint indeholder en række faste elementer, også kendt som artefakter og ceremonier. Det er eksempelvis back-log, sprint planlægning, retrospektive møder, estimeringsmøder og daglige stå-op-møder, og der lægges op til en konform og ceremoniel tilgang til de indbyggede elementer.

Alt sammen med den gode hensigt, at teamet tvinges til at gennemgå og udføre nogle vigtige processer og handlinger, der blandt andet skal sikre, at teamets selvforvaltning styrkes, og at teamets effektivitet i sidste ende øges.

Jeg har oplevet SCRUM fungere adskillige gange med stor succes, både som udførende på teams, som SCRUM Master og som SCRUM Product Owner. Men i forhold til agilitet er det min erfaring, at der opstår visse tilstande af forhindret agilitet, som både kan opleves af teamet indefra og af ledere og kunder udefra.

Indefra opleves forhindret agilitet eksempelvis, når en opgave viser sig at være sværere og mere tidskrævende end forventet med det resultat, at der pludselig bruges mere tid på at tale om opgaven end rent faktisk at arbejde på den. Hvad gør man så? Venter til sprintet er slut og erkender sit nederlag? Udefra opleves forhindret agilitet eksempelvis, når der opstår en situation, hvor ”nogen” mener, at der er andre opgaver, der er vigtigere at tage fat på lige nu og her.

Når SCRUM forhindrer agilitet
Den forhindrede agilitet opleves specielt stærkt, når den, der forsøger at reagere agilt enten indefra eller udefra, mødes med argumenter som: ”Desværre, det kan ikke lade sig gøre, for når vi kører SCRUM, kræver det at…” (find selv på argumentet).

Pludselig bruges SCRUM-aftalerne som noget, der forhindrer agilitet og endda som noget, der i visse situationer strider imod sund fornuft og måske forhindrer, at der findes en lavpraktisk løsning.

Hvis man ofte oplever forhindret agilitet i et SCRUM-setup, kan tiden være kommet til at kigge på metoden KANBAN, der sætter mere fleksible rammer omkring et team og fokuserer på, at teamet løser så mange opgaver så hurtigt som muligt på kortest tid.

Det kan også være, at SCRUM stadig er det rigtige valg, men at det er på tide at fjerne blikket fra SCRUM-biblen, kigge op, identificere forhindret agilitet og gå i løsnings-mode i forhold til at forhindre dette. Eksempelvis ved at tilrette SCRUM-processerne eller hele organiseringen omkring SCRUM. Måske kan det også være tid til at hyre en agil coach, der kan gå processerne efter i sømmene?

Hvad synes du? Skriv gerne en kommentar eller direkte til mig på jbg@arosit.dk

Om forfatteren:

Jørgen er certificeret Scrum Master og Scrum Product Owner. Han har arbejdet med IT-udvikling siden 1996 og har været selvstændig siden 2007. I 2011 indtrådte han som medejer af Aros IT.

Læg en kommentar