Dysfunktionelle Scrum-processer er stærkt udbredte

Jeg har med årene deltaget i snart en håndfuld ‘versioner’ af Scrum, hvor effektueringen variererede i både kvalitet og i forståelse. Jeg har oplevet Scrum, som var etableret gnidningsløst, om end begreber og processer især fortsat vil være en øvelse.

Jeg har også oplevet Scrum, der blev praktiseret ingenlunde gnidningsfrit, og hvor det var tilfældigheder, der afgrænsede hvad Scrum egentlig var for en størrelse.

Jeg har oplevet alle andre end udviklere sendt på Scrum-kursus, og det var ikke usædvanligt at se hele hold af udviklere, der var stærkt begrænset i deres blik for Scrum.

Jeg har sågar måtte sande, at Scrum aldrig burde være foretrukket som metoden til lige præcis den organisation og de opgaver, den skal løse.

Men det er/var et buzzword, og derfor må Scrum være den rigtige metode for den organisation også.

Når vi anvender Scrum, men ikke formår at efterkomme hovedtankerne bag Scrum, så kaldes det for ScrumBut.

»We use Scrum, but…«

I de mest dysfunktionelle Scrum-eksekveringer ses en traditionel ledelse ofte indtage en uindskrænket kontrol over processen, og hvor Scrum er devalueret til et forvokset opgavestyringsværktøj, der blot er tilsløret med Scrum-begreber.

Det er selvfølgelig ledelsens gode ret til at lede en proces og tolke begreber, som de mener er bedst for deres organisation, at diktere Story Points som værende timer osv., men så er det ikke Scrum.

Dysfunktionelle Scrum-processer er så udbredte i dag, at selv en af hovedpersonerne bag det agile manifest vil sige, at Scrum ikke længere er en agil udviklingsproces, fordi Scrum har udviklet sig til at blive ledelsens proces.

Og hvis ledelsen udelukkende er organisatorisk, så vil Scrum også være tilbøjelig til at glemme tekniske discipliner som Test Driven Development, Continuous Integration, Simple Design, Refactoring, Pair Programming osv.

Så hellere afstå fra at kalde det Scrum. Forestil dig, at du bliver ansat på baggrund af dine erfaringer med Scrum, og det sidenhen viser sig ikke at være Scrum, det du kommer til at arbejde under.

Det er lidt som at blive ansat på baggrund af ens erfaringer med objektorienteret programmering, men det software, du skal arbejde med, viser sig ikke at være objektorienteret.

Fundamentale tanker bag Scrum

Der er nogle helt fundamentale tanker bag Scrum, som vi bare ikke kan vælge fra efter smag og behag. Blandt andet, at et Scrum-team er tværfunktionel. Oftest ser vi teams bestående udelukkende af udviklere, og ligeså ofte er det blot de samme udviklere fra de samme teams, som allerede figurerede i organisationen før Scrum blev implementeret.

Det er jo hovedsummen i Scrums selvorganiserede teams, at de kan løse opgaver uanset udfordringerne på tværs af funktioner, fag og afdelinger. Jeg har set teams gå i stå med en opgave, fordi det kræver en indsats fra et andet team eller en anden afdeling.

Scrum er også en metode, vi kun vil vælge, hvis vi ikke ved, hvad vi (eller kunden) vil have. Hvis vi allerede ved, hvad vi vil have, så er det nærmest omsonst at bruge Scrum.

Måske ved vi, hvilke features vi vil have, men vi ved bare ikke hvordan de skal virke – eller rettere, vi har svært ved at specificere kravene til de ønskede features.

Scrum tillader, at kravene til en feature ændres, hvis det første resultat ikke er tilfredsstillende. Det er helt legitimt og en grundtanke i Scrum, at vi (eller kunden) kan ændre mening under processen.

I så fald skal vi igennem endnu en iteration, og op til flere, indtil vi (eller kunden) er tilfreds med resultatet. En traditionel ledelse vil formentlig have svært ved at acceptere, at de oprindelige tidsestimeringer (ikke estimeringer) ikke holder, fordi de forventer at en feature er færdig i første iteration.

Derfor vil en udtømmende specificering af krav til en feature også være fremherskende før en tidsestimering kan finde sted, fordi et team unægteligt vil blive stillet til ansvar for produktet af første iteration – og de får kun den ene iteration til rådighed for at fremstille et tilfredsstillende resultat.

Og hvad var meningen med at overgå til Scrum fra de udskældte vandfaldsmodeller og deres evindelige krav til udtømmende kravspecifikationer?

Story Points

Det er lidt ironisk, at Scrum lover mere præcise estimeringer i Story Points end absolutte estimeringer, men vi ser også et stadigt solidt greb om traditionelle tidsestimeringer.

Det har vist sig at være lidt for abstrakt, at forstå sammenhænget mellem tidligere opgaver og fremtidige opgaver i faktorer – selv for udviklere, men især for en traditionel ledelse, der bare ønsker mandetimer i deres regneark fremfor alt andet.

Derfor er det heller ikke sikkert, at en ledelse vil være tilbøjelig til helt at afmontere tidsestimeringer på samme måde som Scrum siger – nemlig at Story Points ikke er tid.

Ligeså ironisk er det, at det er muligt at omregne Story Points til tid, hvis faktorer som Baseline og Velocity er kendt, og hvor meget Capacity et team har mulighed for at lægge i hvert Sprint fremover. Vi kan arbejde med flere faktorer, men Story Points og Velocity er et minimum for at omregne til tid.

Der er andre agile metoder

Scrum er heller ikke den eneste agile metode, der findes, men det er den mest hypede. Vi har Kanban, Lean, XP, DSDM, FDD, ASD, AUP, RAD, Crystal m.fl., og så er der hybrider som ScrumBan osv. Hver metode med hver deres styrker og svagheder – og med hver deres særegne bærende dele.

Er det features vi har problemer med at implementere? Så var Feature-Driven Development (FDD) måske en mere passende metode at foretrække fremfor Scrum.

De mener begge at være agile, minder om hinanden, men hvor Scrum har manglet, så har FDD en klart defineret proces og milepæle, der er lette at forstå. FDD benytter tilmed traditionelle roller, som både udviklere og en traditionel ledelse vil kunne forstå, og som samtidig kan stimulere en solid teknisk ledelse.

FDD lover i hvert fald at kunne give en bedre anskuelse af features – alene titlen sender et kraftigt signal til alle om, at det er features, der er de bærende dele i processen. Hvor Scrum forsøger at lave iteration gennem implementering, så forsøger FDD at lave iteration allerede på domæne-niveau.

Når jeg læser, at Scrum kan bruges af alle og til alt, så tror jeg nu mere på, at det er hype. Dysfunktionel Scrum, eller ScrumBut, derimod, kan helt sikkert bruges af alle og til alt. Forstå mig ret; Scrum kan blive godt, dér hvor det kan passes ind i en organisation og de opgaver, den skal løse.

Konsekvens af ScrumBut

Når vi implementerer Scrum under en traditionel ledelse, som ikke er parat til at ændre på den fremherskende kultur i organisationen, så vil der opstå spændinger – latent eller helt i det åbne.

På den ene side vil ledelsen ikke give afkald på de roller og den kontrol, den har, men gerne høste en øget produktivitet, slippe for dokumentation, og alt det Scrum stiller dem i udsigt, og på den anden side kan teams ikke blive selvorganiserende, agile, og alt det som Scrum har stillet dem i udsigt.

Scrum-begreberne mister værdi, og der udbryder en sand strid om ord og et modsætningsforhold mellem en ledelse, afdelinger og et team, og sågar teams imellem, som giver masser af grobund for kontroverser, disharmoni, konflikter, mistillid, friktioner, gnidninger, fnidder og fnadder, fordi det pludselig er op til hvem som helst, at tolke hvad Scrum indebærer og omfatter af ansvars-, opgave-, byrdefordeling.

Det er dysfunktionelt, og der er kun plads til en triumfator – den herskende kultur. Og i yderste konsekvens betyder det en forværring af udviklernes arbejdsvilkår.

Bent Normann Olsen har mange års erfaring med desktop softwareudvikling i større og mindre projekter, både i det offentlige og i det private, lige fra hørelære til utility software for protection and power management controllere. Han har især helliget sig object-oriented programming og component-oriented programming, og de seneste år arbejdet som Software Architect for et mindre team i et meget stort projekt hos en middelstor international virksomhed.