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?

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.

Vad är orsakerna till 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:

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

“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.

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

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