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?
I praksis lykkes det desværre altid organisationer at indføre Scrum og gøre deres teams alt andet end agile. Dette omtales ofte som "Zombie Scrum".
Hvad er "falsk Agile"?
"Fake Agile" henviser til teams, der officielt arbejder med agile rammer og metoder uden at have egentlige læringssløjfer med kunderne. Fake Agile betyder derfor, at enten a) inkrementer ikke leveres iterativt til kunderne i første omgang, eller b) direkte kundefeedback på inkrementet ikke bruges til kortsigtet prioritering.
Hvad er årsagerne til Fake Agile?
Der er mange grunde til "falsk Agile". Efter min erfaring er de mest almindelige årsager til falsk Agile i praksis 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
"Når et tiltag bliver et mål, ophører det med at være et godt tiltag."
Fake Agile Årsag #3: Dogmediktaturet
Ingeniører elsker, når der er faste regler for alting. Det gør processer planlægbare.
Så hvordan ville det være, hvis vi også kunne definere 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