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 alltid införa Scrum och göra sina team allt annat än agila. Detta kallas ofta för "Zombie Scrum".
Vad är "Fake Agile"?
"Fake Agile" avser team som officiellt arbetar med agila ramverk och metoder utan att ha faktiska inlärningsslingor med kunder. Fake Agile innebär därför att antingen a) inkrement inte levereras iterativt till kunderna i första hand eller b) direkt kundfeedback på inkrementet inte används för kortsiktig prioritering.
Vad är orsakerna till Fake Agile?
Det finns många anledningar till "Fake Agile". Enligt min erfarenhet är de vanligaste orsakerna till falska Agile i praktiken 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 vi säga så mycket mer om story points år 2025? Jag tror att vi alla har fått erfara hur mycket ett fokus på hastighet 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
"När en åtgärd blir ett mål upphör den att vara en bra åtgärd."
Fake Agile Orsak #3: Dogmadiktaturen
Ingenjörer älskar när det finns fasta regler för allt. Det gör processer planeringsbara.
Så hur skulle det vara om vi också kunde definiera våra arbetsmetoder helt och hållet med regler – Skulle det inte vara fantastiskt? Nej, det skulle det inte vara.
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