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?

Leider schaffen es Organisationen in der Praxis immer wieder Scrum einzuführen und die Teams dadurch alles andere als agil zu machen. Man spricht dann häufig von “Zombie Scrum”.

Was ist “Fake Agile”?

“Fake Agile” bezeichnet Teams, die zwar offiziell mit agilen Frameworks und Methoden arbeiten, ohne dabei tatsächliche Lernschleifen mit Kunden zu haben. Fake Agile bedeutet also, dass man entweder a) erst gar nicht iterativ Inkremente an Kunden liefet oder b) das direkte Kundenfeedback zum Inkrement nicht für die kurzfristige Priorisierung nutzt.

Hvad er årsagerne til Fake Agile?

Gründe für “Fake Agile” gibt es viele. Die häufigsten Ursachen in der Praxis für Fake Agile sind meiner Erfahrung nach folgende:

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.

Wie wäre es also, wenn wir unsere Arbeitsweisen auch komplett mit Regeln festlegen - wäre das nicht toll? Nein, wäre es nicht.

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