Fake Agile: Er alle Scrum-team smidige?
Nei, dessverre er ikke alle Scrum-team faktisk smidige.
La meg forklare: Et Scrum-team er definert ved at det jobber i henhold til Scrum-rammeverket: Det har altså sprinter, bestemte roller og ritualer. Og siden formålet med Scrum-rammeverket er å hjelpe team med å jobbe smidig, burde Scrum automatisk gjøre alle team smidige, ikke sant?
Dessverre er det i praksis alltid organisasjoner som innfører Scrum og gjør teamene sine alt annet enn smidige. Dette omtales ofte som "Zombie Scrum".
Hva er "falsk Agile"?
"Fake Agile" refererer til team som offisielt jobber med smidige rammeverk og metoder uten å ha faktiske læringssløyfer med kundene. Falsk Agile betyr derfor at enten a) inkrementer ikke leveres iterativt til kundene i første omgang, eller b) direkte tilbakemeldinger fra kundene på inkrementet ikke brukes til kortsiktig prioritering.
Hva er årsakene til Fake Agile?
Det er mange årsaker til "falsk Agile". Etter min erfaring er de vanligste årsakene til falske Agile i praksis som følger:
Falsk Agile Årsak #1: Ingen tilbakemeldinger fra kunder
Hvis et smidig team ikke får direkte tilbakemeldinger fra brukerne, kan det ikke jobbe smidig. I praksis blir kundeforespørsler ofte formulert av ledelsen og videreformidlet til teamene via produkteiere – Reelle tilbakemeldingssløyfer med kundene forvitrer eller eksisterer ikke engang.
Et smidig team trenger direkte kundekontakt!
Fake Agile Årsak #2: Fokus på hastighet og historiepoeng
Puh, trenger vi å si så mye mer om story points i 2025? Jeg tror vi alle har erfart hvor mye fokus på hastighet og story points står i veien for kundefordelene.
Et eksempel: Hva skjer hvis en funksjon formelt sett er klar etter første iterasjon, men ennå ikke har oppnådd kundefordelen? Hvis kundefordelen er viktig for oss, jobber vi med den til kundefordelen faktisk er oppnådd. Til slutt kan det ta tre iterasjoner, men nå er kunden i det minste fornøyd.
Men vent, nå kommer plutselig lederen min rundt hjørnet og klager over at teamet mitt realiserte færre historiepoeng i den siste sprinten. Så det hadde vært bedre for hastigheten min om vi rett og slett hadde forlatt den ikke-verdifulle funksjonen og jobbet direkte med neste funksjon, slik at vi kunne skape flere historiepoeng.
For noe tull, ikke sant? Hvis vi gjentar denne prosessen i noen måneder til, vil vi ha et produkt med mange funksjoner som skaper svært liten kundefordel.
Det er derfor ikke overraskende at både kunder og utviklingsteam blir misfornøyde og slutter.
Mer generelt handler dette om en etter hvert velkjent lov: Goodhardts lov
"Når et tiltak blir et mål, slutter det å være et godt tiltak."
Falsk Agile Årsak #3: Dogmediktaturet
Ingeniører elsker når det finnes faste regler for alt. Det gjør prosessene planleggbare.
Så hvordan ville det vært om vi også kunne definere arbeidsmetodene våre helt og holdent med regler –, ville ikke det vært flott? Nei, det ville det ikke.
Bare med Scrum og de mange reglene og retningslinjene som følger med, føles smidig arbeid for mange team allerede som å jobbe etter rigide retningslinjer. Slik bør det ikke være. Så ikke gjør det verre ved å legge til flere regler og retningslinjer for smidig arbeid.
I de beste agile teamene jeg kjenner, føles arbeidet menneskelig, livlig, spontant og samarbeidsorientert. I de fleste agile team gjør det riktignok ikke det.
Agile-teamene må i det minste ha nok frihet til å kunne samarbeide fleksibelt med kundene. Hvis regler og prosesser hindrer dette, bør reglene og prosessene gås etter i sømmene.
I dette innlegget har jeg allerede skrevet spesifikt om trinnene som kreves for å beskytte Scrum-team mot Zombie Scrum: Fiks Zombie Scrum
Falsk Agile er ekte: Hvordan beskytte deg selv?
Ingenting beskytter deg fullt ut mot falsk smidighet. Men det er én ting som kan beskytte deg så godt som mulig: En effektiv prosess sentrert rundt kontinuerlig forbedring.
Dette starter selvsagt med gode retrospektiver der teammedlemmene åpent kan dele sine synspunkter og effektivt utlede og iverksette tiltak for forbedring.
Så lenge denne prosessen fungerer, er ikke potensialet for reell smidighet i teamet ditt tapt.
Hvis du vil ta dine agile retrospektiver til neste nivå, anbefaler jeg –naturally – Echometer, vårt verktøy for retrospektiver. Du kan prøve det gratis her: Prøv Echometer