Ikke alle Scrum-team er smidige: Fake Agile

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 klarer organisasjoner i praksis stadig vekk å innføre Scrum og dermed gjøre teamene alt annet enn agile. Man snakker da ofte om «Zombie Scrum».

Hva er «Fake Agile»?

«Fake Agile» betegner team som offisielt jobber med agile rammeverk og metoder, uten å ha faktiske læringsløkker med kunder. Fake Agile betyr altså at man enten a) ikke leverer inkrementer til kunder iterativt i det hele tatt, eller b) ikke bruker den direkte tilbakemeldingen fra kunden på inkrementet til kortsiktig prioritering.

Hva er årsakene til Fake Agile?

Det er mange grunner til «Fake Agile». De vanligste årsakene til Fake Agile i praksis er etter min erfaring følgende:

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

«When a measure becomes a target, it ceases to be a good measure.»

Falsk Agile Årsak #3: Dogmediktaturet

Ingeniører elsker når det finnes faste regler for alt. Det gjør prosessene planleggbare.

Hvordan ville det vært om vi også fastla våre arbeidsmåter fullstendig med regler – ville ikke det vært flott? Nei, det ville det ikke vært.

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