Ikke alle Scrum-hold er agile: Fake Agile

Fake Agile: Er alle Scrum-team agile?

Nej, desværre er det ikke alle Scrum-hold, der rent faktisk er agile.

Lad mig forklare det: Et Scrum-team er defineret ved at arbejde i henhold til Scrum-rammen: Så det har sprints, bestemte roller og ritualer. Og da formålet med Scrum-rammen er at hjælpe teams med at arbejde på en agil måde, burde Scrum automatisk gøre alle teams agile, ikke?

Desværre sker det igen og igen i praksis, at organisationer forsøger at indføre Scrum og dermed gør teams alt andet end agile. Man taler så ofte om “Zombie Scrum”.

Hvad er “Fake Agile”?

“Fake Agile” betegner teams, der officielt arbejder med agile frameworks og metoder, uden at have faktiske læringssløjfer med kunderne. Fake Agile betyder altså, at man enten a) slet ikke leverer iterative inkrementer til kunderne eller b) ikke bruger den direkte kundefeedback på inkrementet til den kortsigtede prioritering.

Hvad er årsagerne til Fake Agile?

Der er mange grunde til “Fake Agile”. De hyppigste årsager til Fake Agile i praksis er efter min erfaring følgende:

Falsk Agile Årsag #1: Ingen kundefeedback

Hvis et agilt team ikke får direkte feedback fra brugerne, kan det ikke arbejde på en agil måde. I praksis bliver kundeanmodninger ofte formuleret af ledelsen og sendt videre til teams via produktejere – Reelle feedback-loops med kunder visner bort eller eksisterer slet ikke.

Et agilt team har brug for direkte kundekontakt!

Fake Agile Årsag #2: Fokus på hastighed og historiepunkter

Puha, behøver vi at sige meget mere om story points i 2025? Jeg tror, vi alle har oplevet, hvor meget et fokus på hastighed og story points står i vejen for kundefordele.

Et eksempel: Hvad sker der, hvis en funktion formelt er klar efter den første iteration, men endnu ikke har opnået kundefordelen? Hvis kundefordelen er vigtig for os, så arbejder vi på den, indtil kundefordelen faktisk er opnået. I sidste ende kan det tage 3 iterationer, men i det mindste er kunden nu glad.

Men vent, nu kommer min leder pludselig rundt om hjørnet og klager over, at mit team realiserede færre story points i det sidste sprint. Så det ville have været bedre for min hastighed, hvis vi bare havde forladt den ikke-værdifulde funktion og arbejdet direkte på den næste funktion, så vi kunne skabe flere story points.

Sikke noget vrøvl, ikke? Hvis vi gentager denne proces i et par måneder mere, vil vi have et produkt med en masse funktioner, som skaber meget lidt kundefordele.

Så det bør ikke komme som nogen overraskelse, når både kunder og udviklingsteams bliver utilfredse og forlader os.

Mere generelt handler det om en nu velkendt lov: Goodhardts lov

“When a measure becomes a target, it ceases to be a good measure.”

Fake Agile Årsag #3: Dogmediktaturet

Ingeniører elsker, når der er faste regler for alting. Det gør processer planlægbare.

Hvordan ville det så være, hvis vi også fastlagde vores arbejdsmetoder fuldstændigt med regler - ville det ikke være fantastisk? Nej, det ville det ikke.

Alene med Scrum og dets mange regler og retningslinjer føles agilt arbejde allerede som at arbejde efter rigide retningslinjer for mange teams. Sådan bør det ikke være. Så lad være med at gøre det endnu værre ved at tilføje flere regler og retningslinjer til agilt arbejde.

I de bedste agile teams, jeg kender, føles arbejdet menneskeligt, livligt, spontant og samarbejdende. Og det gør det ganske vist ikke i de fleste agile teams.

Agile-teams skal i det mindste have tilstrækkelig frihed til at kunne samarbejde fleksibelt med kunderne. Hvis regler og processer forhindrer dette, bør de undersøges nærmere.

I dette indlæg har jeg allerede skrevet specifikt om de skridt, der skal til for at beskytte Scrum-teams mod Zombie Scrum: Fix Zombie Scrum

Falsk Agile er ægte: Hvordan beskytter du dig selv?

Intet beskytter dig helt mod falsk agilitet. Men der er én ting, som kan beskytte dig så godt som muligt: En effektiv proces centreret omkring løbende forbedringer.

Det starter selvfølgelig med gode retrospektiver, hvor teammedlemmerne åbent kan dele deres synspunkter og effektivt udlede og implementere forbedringstiltag.

Så længe denne proces fungerer, er potentialet for reel agilitet i dit team ikke gået tabt.

Hvis du vil tage dine agile retrospektiver til det næste niveau, anbefaler jeg –naturally – Echometer, vores værktøj til retrospektiver. Du kan prøve det gratis her: Prøv Echometer