Hvad er der galt med Scrum?

Scrum-metoden er efterhånden optaget i mainstream-udvikling - i hvert fald i de kredse jeg oftest bevæger mig i - og det betyder at der kommer flere og flere Scrum-historier.

Som alle andre metoder har Scrum sine stærke og svage sider og i denne omgang vil jeg nøjes med at fokusere på de svage. Jeg har brugt det sidste år på at rende rundt til foredrag og brugergruppemøder, hvor jeg har mødt en masse ligesindede, hørt på deres hårdt indtjente erfaringer og såmænd har jeg også haft tid til at få mine egne erfaringer.

En af mine konklusioner er, at et af Scrums svageste punkter er rollen som Product Owner. Rollen bliver efter min mening oftest undervurderet, i Scrumlitteraturen oftest hoppet lidt hen over og i foredrag fokuseres der oftest på Product Ownerens snitflade med Scrumteamet og meget lidt på arbejdsindhold og snitfladen til projektets stakeholders. Og det er naturligt. Scrum er for udviklerne/nørderne og det er sjældent at Product Owneren er en af dem. Det er en rolle som er lidt omgivet af magi - der opstår en vision for produktet, en viden om domænet, en backlog og en prioritet af opgaver ud af det blå som Scrumteamet så kan arbejde ud fra.

Og måske fordi litteraturen (forbehold: altså det jeg har læst) ikke beskæftiger sig så meget med Product Owner-rollen er den oftest undervurderet og går lidt for ofte til den man nu kan undvære til at gøre arbejdet. Eller måske er den slet ikke vurderet da det er kunden der stiller en product owner til rådighed og det kan være kunden ingen erfaring har med Scrum og dermed ingen viden - men hvor svært kan det være? Mit svar: meget svært.

Rollen som product owner er så uhyre vigtig for projektets succes og det er en politisk svær plads at sidde i. På den ene side ønsker man en stærk product owner som kan tage de politiske tovtrækkerier der kan være i et projekt og som kan stå inde for sine visioner for produktet, og på den anden siden ønsker man en product owner som kan lytte og lade sig vejlede af stakeholders og scrumteamet.

Så det er mit bud på en af Scrums svagheder - hvad er dit bud?

Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Ole Belhage

Som dog nævner en "Product Owner"...

Men intet vil lykkes, så længe vi tænker "metoder/patterns/agile/..." eller anden fag-specifik metodik!

I den virkelige verden skal der nok bruges didaktik (om ikke pædagogik!) - IT er, i bedste fald, et middelmådigt værktøj.

Og IT-folks ufattelige mangel på indsigt i brugerens verden er den største og vedvarender hæmsko for "it-samfundets" faktistke udviklingsmuligheder!

Så i "Scrum"-folks lilleput verden er det også en korrekt iagtagelse at "Product Owner" er et "problem"!

Må Vi Alle Lære Mere
Lars Ole

Michael Møller

Der er mange ting, men man kan jo altid starte med at læse Manifesto for Agile Software Development. Og for at tage den med det samme, så ved jeg godt at grunden til at de Scrum projekter jeg har været med i har fejlet, det er selvfølig at vi ikke har kørt Scrum rigtigt, så er det på plads.

"Individuals and interactions over processes and tools"

Nej, du skal hver eneste dag fortælle hvor lang tid du arbejdet på en task, som du forinden har estimeret, så enhver kan regne ud hvornår du burde være færdig. Hvis dit team fejler er det ikke Scrum der er noget galt med, det er dig. Mennesker fejler, det gør processen ikke. Det ville være bedre hvis der stod Software og afhængigheder frem for processer.

Working software over comprehensive documentation"

Nej, du får ikke software der virker ved at køre Scrum, det får du ved at have en fornuftigt arkitektur uanset hvordan den så er dokumenteret, hvis du arbejder alene er den inde i dit hoved. Du for software der virker, ved at de folk der arbejder med den ved noget om de dele de skal lave og forstår det stykke softwares afhængigheder så vidt og så tidligt så muligt, det kræver specialister og ikke ”cross functional teams” på 5 til 9. På den måde sidder alle specialisterne alene og alle kan potentielt trække en hvilken som helst task ned fra tavlen hvad enten du er specialist eller ej.

"Customer collaboration over contract negotiation"

Det gælder så ikke teamet, for i skal som team blive enige med produkt owneren om hvad sprint målet skal være.
Menings fyldte mål skal kun måles, og produkt owneren kan forvente at få software demonstreret selv efter første sprint. Og jeg har set flere teams, skrive under på tavle at de kunne stå inde for sprint målet og den planlægning de havde udført, såeh contract negotiation?. Man starter ikke med det der er har størst "business value" i starten af et sprint. Man starter med det stykke af softwaren der har de største usikkerheder så man hurtigt kan få dem af vejen eller stoppe projektet.

"Responding to change over following a plan"
Nej, det er ikke at håndtere ændringer at skære noget at et sprint for derefter at putte det ind i et andet sprint senere. Det er heller ikke at sige jeg er ikke bange for nye krav, for det kan du sige nok så mange gange, men hvis din arkitektur ikke har netop det som kvalitets attribut, og dit design ikke tillader ændriger, så hjælper det dig ikke at du er agile.

Michael Mortensen

Som nu en gammel gris i stalden, så vil jeg mene at SCRUM modellen er en gevinst for såvel virksomhed som medarbejder - så længe man husker der ikke er nogen fastsat skabelon for SCRUM modellen.

Bevares, der er nogen retningslinier som bør overholdes, men det betyder ikke, at man ikke kan krydre den med noget af det gode fra eks. MSF modellen.

I fht. product owner, så er det min erfaring, at det team jeg er en del af rent faktisk får leveret det de ønsker - og som regel mere til. Løbende som virkeligheden ændre sig, ændre prioriteringen sig. Og ja, i starten er det en anelse frustrerende, men det overvinder man i fht. glæden ved at levere det ønsket.

Fællesnævneren for succes er DIALOG og FORSTÅELSE.
På et personligt plan har SCRUM modellen tilføjet så utrolig meget til min bagage, at jeg godt tør garantere fuld tilfredshed til produkt ejeren.

Faktisk har jeg svært ved at tænke tilbage på de til tider skyttegrave der kunne opstå mellem forretning og udvikling - nu er det homogent organisationen igennem.

Michael Rasmussen

Den største fejl, jeg ser i Scrum, er, at de manglende metoder til fremstilling af produktet. Så hvis metodesvage firmaer/teams adopterer Scrum som model, er der alvorlig fare for fiasko, hvis de tror, Scrum er svaret på enhvert spørgsmål. Scrum er glimrende til projektstyring og behovsafstemning, men når vi når til selve produktudviklingen, skal værktøjer/metoder fra andre modeller på banen. I engelske termer vil man kalde Scrum en methodology.

Sat på spidsen: Scrum kan ikke stå alene; dem der siger noget andet, har faktisk misforstået det hele!

PS. Det er mig en gåde, at XP ikke har fået større gennemslagskraft i Danmark. Efter min bedste overbevisning har XP nemlig både et bud på projektstyring, brugerinddragelse og metoder/værktøjer til produktudvikling.

Michael Svendsen

Jeg er Prod. Owner (PO), i et IKKE SW udviklings miljø, men derimod i infrastruktur projekter - servere netværk etc.
Det er ikke nemt at indføre dette i et team som ikke har kolleger som man kan diskutere scrum med

Rollen som PO. er i begyndelsen ekstremt tidskrævende, faktisk full time for et lille team på 6.
I starten troede jeg at jeg skulle lave andet også men....
Efterhånden kan jeg vel klare det på 25-30% af min arbejdsdag.

Det er hårdet arbejde at forstå kundens ønsker og få dem lavet til backlog.

Det er hårdt arbejde at hjælpe kunden med at oversætte de tekniske muligheder teamet kommer med.

Det er hårdt arbejde at få teamet til at fortælle og estimere alle de "mellemled" som er nødvendige for at få ønsker til at være et færdigt produkt. Jeg har mange gange fået svaret "det har du jo ikke sagt" eller jeg troede forudsætningen for opgave X var lavet, når jeg ikke rigtigt kunne se anvendelsen for noget som eller kunne demonstreres. Dette skyldes naturligvis også at jeg ved meget mindre teknisk end teamet.

Men vigtigst af alt PO arbejde er en Produkt Backlog (og scrum ditto) som kan læses og forståes af kunden og teamet, og konstrueret en overskuelig backlog således at den kan prioriteres.

Det sidste har taget mig mange iterationer, men jeg tror ikke der er nogen silverbullit til denne del.
Vi har prøvet Sharepoint, Excel og papir lapper, til at vi nu kører en uskøn blanding, men folk siger det virker.
Backloggens tool er her hvor mennesker kommer først. Hvis der ikke er nogen som forstår backloggen, finder den uoverskuelig, eller for besværlig er scrum tabt.

Det som jeg ser fordelen af (og de fleste i teamet), er at man ikke får 2-3-4-17 opgaver, som chefen siger SKAL være færdig på samme tid, at de alle er lige vigtige, og at de skulle være færdige igår, sidste-uge-måned osv.
Man kan lave ÉN opgave ad gangen, lave den færdig, helt færdig, videre til næste opgave.

For de personer i teamet, som kan lide at lave tingene færdige, er scrum godt - super godt.
For personer som kan lide at rode, få startet på sjove opgaver, men mister interessen når idéer er tænkt, lavet nogle hacks og set at det er muligt og virker delvist, og mener "det kan jeg fikse lidt på engang", er scrum et super værktøj for virsomheden/kunden til at få tingene færdiggjort.
Sidstnævnte holder dog ikke i længden, da han syntes "scrum er s'.. noget bøwl" og "ham PO. er s'.. da en dum skid, som råber af ham hvert sprint review over at der mangler lidt hist og pist".

Til sidst: er der andre her, som bruger scrum til andet end SW kodning? Det virker faktisk!

Michael Rasmussen

En grov sammenligning af Scrum og XP:

Scrum er udtænkt af projektledere/arkitekter for projektledere/arkitekter, mens XP er udtænkt af programmører for programmører/arkitekter/projektledere.

Scrum er designet med henblik på at forenkle og strømligne processen, mens XP har til formål at sikre en minimal gennemtestet kodebase, der præcist leverer det lovede.

Af prominente personer indenfor XP kan nævnes Kent Beck, Martin Fawler og teamet bagved GOF-mønstrene - Erich Gamma, Richard Helm, Ralph Johnson og John Vlissides

Michael Møller

"Sat på spidsen: Scrum kan ikke stå alene; dem der siger noget andet, har faktisk misforstået det hele!" -

Det er bestemt ikke at sætte nogen på spidsen - for Scrum er jo ikke en udviklingsmetode, men et projekt styringsværktøj, derfor kan Scrum ikke stå alene i software projekter. Jeg ville sådan ønske at vi ville høre mere om software udviklings metoder, end om projekt styrings metoder.

Jesper Louis Andersen

Af prominente personer indenfor XP kan nævnes Kent Beck, Martin Fawler og teamet bagved GOF-mønstrene - Erich Gamma, Richard Helm, Ralph Johnson og John Vlissides

De bevidste provokationer: Læs indgående hvad de her folk har skrevet. Det er meget vigtigt. Gør så noget i stik modsat retning af det de siger :)

Det jeg godt kan lide i Scrum er ideen om at man med jævne mellemrum kommer "tilbage" til et fast ståsted ved sprint-afslutninger. I mange Open Source projekter sker det samme, men "sprints" er noget mere "desynkroniserede". Hver mindre feature er sit eget "sprint" med sine egne udviklere og når den er færdigudviklet, så bliver den flettet ind i produktionen (efter noget test velsagtens).

Det jeg mindst kan lide ved Scrum er ideen om at have en Product Owner. Det er en rigtigt dårlig ide at lade resten af virksomheden være "kunde" som "køber" et produkt af udviklingsafdelingen. Hvis man ikke passer rigtigt godt på leder det nemlig til løsninger på de forkerte problemer og udviklingen ender med at skulle vedligeholde kode der slet ikke var nødvendig.

Ole Wolf

Jeg har set Product Owner og Scrum Master blive givet til den samme ene person, hvorved man i praksis stod i samme situation som før, hvor projektlederen bestemte, hvad der skulle laves, samtidig med at projektlederen løb fra ansvaret for, at det blev gjort ordentligt. Mens Product Owner i bund og grund bare vil have sit produkt hurtigst muligt, og kan blæse på, hvordan det bliver lavet, er Scrum Master ansvarlig for, at Scrum-teamet følger processen, også hvis det betyder, at produktet ikke bliver lavet ordentligt. Det betyder, at selv i teorien vil det gå galt, hvis disse to roller bliver givet til den samme person.

Et andet problem, jeg er stødt ind i, er at Scrum er blevet brugt som argument mod at følge de nødvendige procedurer såsom verifikation eller overvågning af processen. Det er mener jeg er helt forkert og misforstået - Scrum kræver mere modenhed og disciplin end et klassisk projekt, samt et ønske om at nå frem til stærke processer.

Jakob Veje Hansen

Therese,

Jeg er helt enig i din analyse, men den problemstilling du påpeger gælder sådan set alle projekttyper, og ikke kun SCRUM projekter. I nogle lidt større projekter (som f.eks. det jeg p.t. sidder med), kan man ikke entydigt pege på 1 person der har den nødvendige indsigt til at påtage sig rollen.

Hvis man tager SCRUM for hvad det er (jeg opfatter det mest som et framework for dagligt team arbejde), kan jeg egentligt ikke se så mange svagheder i metoden. Men jeg kan tilgengæld se rigtigt mange problemstillinger hvis man tror man kan nøjes med SCRUM metoden.

Ivar Albæk Hansen

Jeg håber jeg må blande mig som ikke-SCRUM ekspert. Der er en ting jeg ikke helt forstår: PO er vel kunden selv, eller en repræsentant for ditto, og er således den der har indflydelse på den funktionalitet der skal leveres? Hvis det er rigtigt så kan jeg undre mig over at det kan give mening at køre SCRUM uden en PO.
Hvis man kører SCRUM uden PO er man vel ikke agil i forhold til kunden/forretningen. Hvori ligger agiliteten så?
Jeg synes det er direkte alarmerende at Therese skriver "Scrum er for udviklerne/nørderne". Hvis man virkelig skal lykkes (med en hvilkensomhelst metode) skal alle interessenter kende deres rolle og ansvar. Nogen skal forstå mere end andre, men PO skal da i særdeleshed forstå arbejdsformen og det ansvar der ligger for det færdige produkt.

Kaj Voetmann

Scrum er fin, men har en detalje fælles med mange metoder til at fremme udviklingsprocesser: Vi leder efter klare og entydige måder at taler om verden på. Roller i en kompliceret, dynamisk udviklingsproces er som i netværksledelse: Uklare og de skifter afhængigt af den form for ekspertise, der er brug for - for at bringe dialog og eksperimenter videre. Det er som at tro, at Edison var fuldt ansvarlig for udviklingen af sine patenter. Eller at John F. Kennedy var ansvarlig for at sende den første mand til Månen. Han kunne være den ansvarlige for missionen, men ideen var central i Jules Verne's gamle bog. Babbages Analytical Machine fra omkring 1833 viste at computeren var mulig, men teknologien var ikke udviklet til at bygge den.

Den organisationsforståelse, der ligger bag de fleste udviklingsmetoder, er sjældent i stand til at beskrive udviklingen fra ide til produktionsmiljø.

Der findes andre organisationsforståelser, som passer meget bedre til udviklingsprocesser. Prøv at kigge på http://kajvoetmanndk.wordpress.com/2009/11/21/nar-vi-teamer-op-i-netv%C3...

Michael Møller

Jeg tror ikke det er roller vi leder efter, men mere hvordan man koordinere sit arbejde i en uklar skabelsesprocess. Hypotetiske spørgsmål i forbindelse med Scrum kunne være:
Hvad sker der hvis to backlog items er teknisk ens i to scum teams på samme tid?. Hvad sker der når et team ligger sig fast på en komponent arkitektur, eller forudsætter noget om software arkitekturen for at nå sit sprint mål, mens en anden gruppe har som sprint mål at definere den?. Det kræver koordination at lave software, og at styre en udviklingsprocess, kreativ eller ej.

Hvis ikke din organisaton ligner din software, kommer din software til at ligne din organisation, uanset hvilken organisations metafor du vælger at se din organisation igennem.

Dennis Decker Jensen

Scrum er en management-metode, ikke en softwareudviklings-metode. "Scrum er for udviklerne/nørderne": Det kan man godt argumentere for, men Scrum er først og fremmest en management-metode, der lægger rammerne for arbejdet.

Scrum er konceptuelt blevet klistret meget sammen med de agile metoder, og det har givet en hel del misforståelser, som er forståeligt nok, da en sprint nemt kan forveksles med en iteration kendt fra agile metoder. Scrum siger intet om, hvordan udviklerne skal lave deres arbejde i sprintet. Der er intet til hinder for at bruge fx David L. Parnas' metoder eller andre til at udvikle software under Scrum-rammerne.

Dine overvejelser angående Product Owner er ikke helt ved siden af. Jeg har været på flere forskellige Scrum-projekter, og min erfaring er også, at uden en stærk Product Owner, som er beredt på at involvere og engagere sig, dvs. rent faktisk tage en dialog med teamet og prioritere, kommer det ikke til at fungere. Det overrasker vel næppe nogen, da det gælder ethvert projekt. Uden involvering fungerer det ikke.

Formulerer Scrum sig vagt? Det er faktisk nok bevidst. Metoden fastlægger som sagt ikke en metode, blot en procesramme. Scrum kan bruges med XP-praksisser som fx Test-First og Continuous Integration, men også i tunge projekter med megen upfront design, en masse dokumentation, og en masse andet slags arbejde. Jeg har prøvet begge dele.

Scrum er naturligvis yderst velegnet til software-projekter, men kan også bruges i andre projekter under lignende betingelser som i software-projekter. Michael Svendsens eksempel ovenfor er meget interessant.

Jesper Madsen

Hvor bliver der taget hånd om software designet i Scrum? Var det ikke bedre at lave en metode der begrænser antallet skiftene krav, så man kan lave noget ordenlig software. Det kan vel ikke være sådan at kundes reelle behov skifter så hurtigt? Min erfaring er også at det er ledere eller sælgere der opstiller kravene, men skulle der ikke være nogle design folk der gjorde det?
mvh
Udvikleren.

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize