Inte alla Scrum-team är agila: Fake Agile

Fake Agile: Är alla Scrum-team agila?

Nej, tyvärr är inte alla Scrum-team faktiskt agila.

Låt mig förklara: Ett Scrum-team definieras genom att det arbetar enligt Scrum-ramverket: Det har alltså sprintar, vissa roller och ritualer. Och eftersom syftet med Scrum-ramverket är att hjälpa team att arbeta på ett agilt sätt, borde Scrum automatiskt göra alla team agila, eller hur?

Tyvärr lyckas organisationer i praktiken gång på gång införa Scrum och därmed göra teamen allt annat än agila. Man talar då ofta om “Zombie Scrum”.

Vad är “Fake Agile”?

“Fake Agile” betecknar team som officiellt arbetar med agila ramverk och metoder, utan att ha faktiska inlärningsloopar med kunder. Fake Agile betyder alltså att man antingen a) inte levererar inkrement till kunder iterativt från början eller b) inte använder den direkta kundåterkopplingen till inkrementet för den kortsiktiga prioriteringen.

Vad är orsakerna till Fake Agile?

Det finns många anledningar till “Fake Agile”. De vanligaste orsakerna i praktiken till Fake Agile är enligt min erfarenhet följande:

Falska Agile Orsak #1: Ingen feedback från kunder

Om ett agilt team inte får direkt feedback från användarna kan det inte arbeta på ett agilt sätt. I praktiken formuleras kundförfrågningar ofta av ledningen och vidarebefordras till teamen via produktägare – Verkliga återkopplingsslingor med kunder tynar bort eller existerar inte ens.

Ett agilt team behöver direkt kundkontakt!

Fake Agile orsakar #2: Fokus på hastighet och berättelser

Puh, behöver man säga så mycket om story points år 2026? Jag tror att vi alla har fått tillräckligt med erfarenhet av hur mycket fokus på velocity och story points står i vägen för kundnyttan.

Ett exempel: Vad händer om en funktion är formellt klar efter den första iterationen, men ännu inte uppnår kundnyttan? Om kundnyttan är viktig för oss arbetar vi med den tills kundnyttan faktiskt uppnås. I slutändan kan det ta 3 iterationer, men nu är kunden åtminstone nöjd.

Men vänta, nu kommer min chef plötsligt runt hörnet och klagar på att mitt team realiserade färre story points under den senaste sprinten. Så det hade varit bättre för min hastighet om vi helt enkelt hade lämnat den icke värdefulla funktionen och arbetat direkt med nästa funktion så att vi kunde skapa fler story points.

Vilket skräp, eller hur? Om vi upprepar den här processen i ytterligare några månader kommer vi att ha en produkt med många funktioner som skapar mycket liten kundnytta.

Det är därför inte konstigt att både kunder och utvecklingsteam blir missnöjda och lämnar företaget.

I mer allmänna ordalag handlar det om en numera välkänd lag: Goodhardts lag

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

Fake Agile Orsak #3: Dogmadiktaturen

Ingenjörer älskar när det finns fasta regler för allt. Det gör processer planeringsbara.

Hur vore det alltså om vi också fastställde våra arbetssätt helt och hållet med regler – vore inte det bra? Nej, det vore det inte.

Bara med Scrum och dess många regler och riktlinjer känns det agila arbetet redan som att arbeta enligt rigida riktlinjer för många team. Det borde inte vara så. Så gör det inte ännu värre genom att lägga till fler regler och riktlinjer för agilt arbete.

I de bästa agila team jag känner till känns arbetet mänskligt, livligt, spontant och samarbetsinriktat. Och det gör det inte i de flesta agila team.

Agile-teamen måste åtminstone ha tillräckligt med frihet för att kunna samarbeta flexibelt med kunderna. Om regler och processer förhindrar detta bör reglerna och processerna granskas.

I det här inlägget har jag redan skrivit specifikt om de steg som krävs för att skydda Scrum-team från Zombie Scrum: Fixa Zombie Scrum

Falsk Agile är verklig: Hur skyddar du dig själv?

Ingenting skyddar dig helt från falsk agility. Men det finns en sak som kan skydda dig så bra som möjligt: En effektiv process som är centrerad kring ständiga förbättringar.

Detta börjar naturligtvis med bra retrospektiv där teammedlemmarna öppet kan dela med sig av sina åsikter och på ett effektivt sätt ta fram och genomföra förbättringsåtgärder.

Så länge den här processen fungerar är potentialen för verklig smidighet i ditt team inte förlorad.

Om du vill ta dina agila retrospektiver till nästa nivå rekommenderar jag –naturally – Echometer, vårt verktyg för retrospektiver. Du kan prova det gratis här: Försök Echometer