Gæstebloggen

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.

Softwarearkitekt Bent Normann Olsen Illustration: Privatfoto

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.

Relateret indhold

Kommentarer (4)
Ivan Skytte Jørgensen

Jeg mener at et af de største problemer er at processen bliver reklameret som at den kan løse alle problemer. Det er ikke unikt for scrum - andre processer er også blevet oversolgt (iterativ, SA/SD, prototyping, ...). Men det, som er unikt, er at der er ret mange som falder for det. Og holdningen er at hvis noget ikke virker ordentlig så er der fordi man ikke følger processen.

Det (rgid holdnng til hvad scrum indebærer) modarbejder at tilpasse og optimere processen til den aktuelle virksomhed og opgave.

Jeg har tidligere skrevet en svada: https://www.version2.dk/comment/335075#comment-335075

Joe Sørensen

Min erfaring er at det tager flere års kamp at indfører Scrum. Det er let at lærer de ord, som bruges i Scrum. Udfordringen er, at alle skal kende formålet med det hele. Gerne i detaljer. Og ledelsen skal vide at, der ikke er nogen fordele at høste under Scrum, hvis man kun lader som om, man kører Scrum. Under denne process, vil der være mistillid, friktioner osv, men det ville der også have været under den MicroManagement signede ledelsesstil som Scrum skal forsøge at erstatte. Jeg kalder denne periode for MicroScrumManagement. Her har ledelsen svært ved at kigge op fra deres regneark ligesom i MicroManagement tiden. Og de ved stadig ikke ved hvad de skal fortælle deres kunder, som jo gerne vil have klarer svar. I denne tid har afholdes de forskellige Scrum ritualer men ofte opnår Scrum møderne ikke det formål, som de skal have ifølge Scrum. Fx tages der opgaver med til planning, som ingen ved hvad går ud på. Til gengæld er de allerede lovet færdig.

Scrum giver netop løsningen på kundens spørgsmål, men ingen stoler rigtig på svaret før de er modne til det. Svaret til kunden kan fx være. at vi kan ikke love at udføre mere til denne dato end udviklerne allerede har lovet. Ellers så havde de lovet mere. Vi kan dog love at kunden kan møde udviklerne, så udviklerne kan hjælpe med at nedbryde opgaven. Derefter kan opgaven estimeres og det kan blive klarlagt hvilke ressourcer kunden selv skal være klar med, når opgaven implementeres. Og nu kan kunden bruge den viden til at vurdere hvilke opgaver der er vigtigst for kunden selv.

Når det endelig at lykkes at implementerer Scrum, så er der frit valg imellem de forskellige Agile metoder. Fordi nu kender alle involverede formålet med de forskellige ritualer og kan kombinerer dem på forskellig vis.

Oliver Billing

Jeg forstå godt budskabet og er enig at der er mange scrum processer der er afsporet er dog uenig i årsagen.

Scrum stiller enorme krav til den enkelte udvikler, ikke nok med at han skal beherske en lang række tekniske discipliner han skal og forstå og afklare brugerens domæne.

Jeg oplever for tit at scrum teams fokuserer alt for meget på at lave det store cirkus, med automatiske test, pair programming osv, for så at levere en løsning der er helt forkert. Vi kan argumenterer at det fikser vi i næste iteration, men det er en meget dyr måde at komme videre på. Tests skal pilles ned, laves om, UI redesignes, osv.

Hvis scrum skal fungerer skal de rigtige mennesker på, et hold der er forkuseret på den forretning de forsøger at løse og bare har teknikken som et stykke værktøj. Så lidt provokerende vil jeg postulere at Scrum er en HR opgave ;-)

Therese Hansen

Jeg tilslutter mig din kritik af Scrum-hypet, Bent. Et af de største problemer med Scrum er den måde metoden bliver solgt.

Scrum er ikke løsningen på alt - det er slet ikke en løsning. Det er et diagnose-værktøj, og løsninger kommer så først derefter (med mindre dine problemer er meget simple). En ledelse der er blevet solgt Scrum som en løsning kan blive overraskede og modvillige over at det kræver mere end Scrums praksisser at løse deres problemer... og så har udviklerne et større problem med synlige, uløste problemer.

Jeg har tidligere skrevet lidt om Scrum som "snake-oil". http://qed.dk/therese-hansen/2016/10/10/scrum-er-ikke-en-loesning/

Log ind eller Opret konto for at kommentere