olav m.j. christiansen bloghoved olav christiansen

Scrum er fragile - ikke Agile

Overskriften siger nok det hele, og jeg har sagt noget lignende i flere af mine blogindlæg efterhånden.

Når jeg nu bringer det på banen igen, er det fordi jeg lige faldt over et friskt blogindlæg på en anden blog, som fint opsummerer nogle af problemerne med Scrum:
Scrum is fragile, not Agile

Dennis Weyland, som skriver bloggen, forklarer bl.a. at guiden til at bruge Scrum slet ikke nævner at det er Agile, men tværtimod lægger meget vægt på at man skal følge de regler, som findes i Scrum frameworket.

Jeg har selv flere gang observeret at man har fået et dårligt resultat ud af at følge Scrum slavisk i stedet for at tilpasse metoderne til situationen og den organisation, hvor de skal bruges, så jeg er helt enig.

Kære læser: Hvad er din erfaring med Scrum og agile? Er det rigtigt at Scrum ikke er rigtigt Agile, og hvad har I så gjort i jeres projekter i stedet for?

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Esben Nielsen

Scrum er "mini-vandfald", hvor man bibeholder en vandfaldsmodel inden for hver iteration: alle opgaver skal være nedbrudt og have klare krav inden man går igang.

Jeg kan personligt langt bedre lide at finde ud af krav og detaljer undervejs: det er mere effektivt og muliggør innovation langt bedre. Det kan snildt være i løbende sparring med en stakeholder. Men på den måde kan et team godt blive opløst i enmandshærer, som løser hver sin opgave.

Scrum er godt hvis estimater er vigtigere end innovation og afvikling af kodegæld, eller for nye udviklere, som ikke har domænekendskab og derfor skal have nedbrudte og præcise opgaver.

I sidste ende tror jeg det bedste resultat opnås med tillid mellem "kunde" og udviklere. For lidt tillid giver for meget fokus på proces og estimater, som igen har det med både at bremse innovation og løbende oprydning af koden og andre indadvendte optimeringer.

  • 3
  • 0
Olav M.j. Christiansen Blogger

Scrum er "mini-vandfald", hvor man bibeholder en vandfaldsmodel inden for hver iteration: alle opgaver skal være nedbrudt og have klare krav inden man går igang.

Jeg mener selv at både Scrum og Agile kan beskrives som en slags minivandfald, men jeg tror nu ikke nødvendigvis Scrum fordrer at alle kravene skal være klare inden man går i gang. Sådan lærte jeg i hvert fald ikke Scrum, da jeg lærte det for nogle år siden.

I øvrigt er der nogle, der mener at der findes flere slags Scrum:
https://blog.agendashift.com/2018/07/04/righttoleft-works-for-scrum-too/

  • 0
  • 0
Casper Bang

Det eneste Scrum vel reelt lover, er at være et arbejdsredskab der kan hjælpe med at:

1) Sørge for at skabe værdi, ved for det første at dedikere en ansvarshavende PO (du får X timers udvikling i næste sprint, hvad er vigtigt for dig og dit produkt til næste release?) og for det andet, holde en iteration så tilpas kort at en evt. forkert vej bliver fanget i tide før det har kostet kassen.

2) Skabe synlighed og fremdrift ved hurtigt at kunne identificere problemer og/eller folk der sidder alene med noget for længe og skal bruge hjælp. Hertil hører også krav til en generel forståelse af hvorledes problemet kan/skal løses i form af Definition of Ready kriterier der skal være overholdt ved planning.

3) Sikre kvalitet ved at blive enige om hvornår opgaven er løst ved at definere nogle Done kriterier og typisk også højere QA kriterier (Done-Done) som, hvis udført korrekt, bliver til en drejebog for testere og evt. dokumentationsskrivning.

Hvad jeg ofte ser går galt, er enten at projektet i virkeligheden er et stort vandfaldspojekt hvor Scrum er mast ned over, og når det er helt galt, det ikke er teamet der tager stories ind men managers/kunde der hælder på. Med andre ord, et succesfuld scrum team skal først og fremmest have lov til at køre efter et pull-princip og ikke push.

Lykkedes dette ikke, må det anbefales at man forsøger en Kanban eller Scrumban stil istedet - da det er nemmere for managers/kunde at forholde sig til en kø samt WIP limit, men så får man typisk også brug for flere states på sit board (Blocked, QA etc.)

Personligt er jeg fan af Scrum når det handler om større projekter (der skal koordineres miljøer, teams, releases) med lange feature-branches og Kanban når det er mindre eller kun mig selv der udfører trunk-based development - ikke mindst når vi faktorerer release af software ind i kabalen også hvor CI/CD er noget nemmere af efterleve i Kanban.

  • 2
  • 0
Morten Nissen

Syntes generelt det er problematisk når man lader processen styre og at man ikke styre processen. Det gør sig gældende for scrum, prince2, itel osv .
Hvis man ikke konstant overvejer hvordan metoden og justere der hvor man vurdere der er uhensigtsmæssigheder så taber vi.

I forhold til om scrum er agile eller ej. Så er det vel teamet og ikke scrum der skal være agilt. Og her ser jeg ikke at scrum står specielt meget i vejen. Men det bliver altid en lidt underlig diskution på ord. Eks. Kan du jo altid hævde at scrums sprintplanlægning gør at du ikke kan reagere hurtigt nok(Og der skal man jo så styre processen og ikke omvendt)

  • 0
  • 0
Olav M.j. Christiansen Blogger

Nogle kommentar

Syntes generelt det er problematisk når man lader processen styre og at man ikke styre processen. Det gør sig gældende for scrum, prince2, itel osv .
Hvis man ikke konstant overvejer hvordan metoden og justere der hvor man vurdere der er uhensigtsmæssigheder så taber vi.

I forhold til om scrum er agile eller ej. Så er det vel teamet og ikke scrum der skal være agilt. Og her ser jeg ikke at scrum står specielt meget i vejen. Men det bliver altid en lidt underlig diskution på ord. Eks. Kan du jo altid hævde at scrums sprintplanlægning gør at du ikke kan reagere hurtigt nok(Og der skal man jo så styre processen og ikke omvendt)

Tak for de gode kommentarer.

I forhold til at det burde være noget, der interessserer mange, og at dette blogindlæg lige nu er blevet læst af over 2000, synes jeg det er meget få, der er kommet med indspark med deres erfaringer.

I forhold til det du siger, tror jeg problemet er at man ofte følger en proces for processens skyld. Hvis man står i en alvorlig situation og skal træffe en beslutning, så kigger man på hvad processen siger. Hvis processen så ikke kan løse problemet, er man lige vidt, for man skal jo følge lige præcis dén bestemte metode.

Pudsigt nok er PRINCE2 på lige det punkt lidt bedre end Scrum, for selv om der er mange flere processer, er det ikke vigtigt at man anvender dem alle slavisk. Det er stadig PRINCE2, selv om man har beskåret nogle af processerne, hvis man bare følger de overordnede principper.

Når man implementerer en bestemt metode, er det vigtigt at man altid tilpasser den til situationen, dvs. organisationen og projektet. Og i den tilpasning, skal man jo så sikre sig at det er mennesker, der træffer de vigtige beslutninger - ikke processer og robotter.

  • 0
  • 0
Chris Bagge

Scrum er, som jeg ser det en meget firkantet process. Dermed er den direkte i modstrid med "the Agile Manifesto"s første punkt "people over processes". Dette er nok årsagen til at Scrum er blevet så populær (hos ledelsen). Samtidigt virker det som om at Scrum forudsætter at teamet lever i sin egen lille beskyttede verden. I min daglige verden er der drift/incidents og de skubbes ikke til næste sprint! Samtidigt har vi en hel del opgaver sammen med andre i virksomheden. Her er det meget svært at forudsige hvad der kommer af opgaver og hvornår. Meget ofte er vi afhængige af svar fra ekstern tredjepart hvor svartid er ukendt.
Scrum arbejder også med et princip med at alle kan håntere alle typer opgaver. Sådan ser vores verden ikke ud. De forskellige medlemmer i teamet har forskellige kompetencer, og supplerer hinanden. Der holdes stand-up møder, men det er mest en afrapportering af hvad man har brugt timer på, ikke hvor langt man er nået, da det er et krav i organisationen. Vi er en verden hvor der er eksterne "regulatory bodies" der kræver at all dokumentation er der. "Running code" er et af trinnene men langt fra det at projektet er færdigt.
Det er i virkelighedens verden også meget svært at få den "project owner" der tales om til at eksistere. Det burde være en fra forretningssiden, men ..

Sidst men ikke mindst så savner jeg en udviklingsmodel der sørger for at der laves en arkitektur og et design før man koder.

Vi gør det, fordi vi skal, og så forsøger vi at holde os "under radarhorisonten" samtidigt med at vi forsøger at levere et produkt med en høj kvalitet.

  • 1
  • 0
Olav M.j. Christiansen Blogger

Scrum er, som jeg ser det en meget firkantet process. Dermed er den direkte i modstrid med "the Agile Manifesto"s første punkt "people over processes". Dette er nok årsagen til at Scrum er blevet så populær (hos ledelsen).

Jeg er meget enig i at Scrum kan virke meget firkantet. Men hvis man bruger Scrum som inspiration og tilpasser den til organisationen og projektet, kan det godt bruges til noget. Problemet er at dem, der opfandt Scrum, ikke mener at det skal bruges på den måde. Det er nærmest 'Scrum or nothing'. Jeg vil prøve at følge op på noget af dette med et lidt længere blogindlæg ved en senere lejlighed.

Hvorfor ledelsen synes at Scrum er populært er nok lidt svært at gætte på. Det kunne jo også skyldes at Scrum på overfladen ser meget enkelt ud. En færdig model, der lige kan trækkes ned over hovedet på organisationen. Men som med alle modeller skal den jo tilpasses, så f.eks. både ledelsen og forretningen deltager i det. Det glemmer man tit, så Scrum kun bruges internt hos leverandøren/IT - og det var ikke det, der var meningen.

Efter min meningen findes der ingen færdige modeller, som kan bruges af alle organisationer uden tilpasning. Så ledelsen slipper ikke for at tænke selv, når de vælger projekt- og udviklingsmodel.

Jeg kom i øvrigt til at lave et nyt lille indlæg pga. den aktuelle politiske situation :-)
https://www.version2.dk/blog/dronningen-scrummaster-1088232

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize