Alt omkring Scrum metoden

I dette indlæg skal vi kigge på Scrum, hvilket i dag er gået hen og blevet en af verdens mest anvendte projektledelsesmetode. Og det er der rigtig god grund til, så lad os dykke lidt ned i det i dette indlæg. Men lad os starte med at kigge på helt grundlæggende hvad Scrum er.

Hvad er Scrum?

Scrum er en agil måde at udvikle innovative produkter og services på. Billedet nedenfor vil vise hvordan denne process ser ud. Denne agile process starter ved at man laver en product backlog, hvilket er en prioriteret liste af opgaver som skal løses for at opnå et succesrigt produkt.

Man bruger så denne prioriteret backlog til at drive projektet ud fra, det gør man ved at sikrer sig at de vigtigste opgaver altid ligger højest i backloggen. På den måde ved man altid hvilken opgave der er den næste man skal gribe, det er nemlig den opgaver som ligger øverst på den prioriterede backlog. Det smarte med denne metode er at hvis du skulle løbe tør for ressourcer i dit projekt, hvad end det er penge eller tid, så ved du altid at du har fået de vigtigste opgaver med i projektet, da du løbende har prioriteret opgaverne.

Man arbejder med opgaverne op en helt speciel måde, for man arbejder nemlig i det som hedder Sprints. Dette betyder at man arbejder i små grupper, hvor man planlægger arbejde 4-6 uger frem i tiden, og fokusere udelukkende på de opgaver. Man laver alt arbejde i sådan sprints, både design, opbygning og test af slutproduktet. Så altså alt hvad der skal til for at færdiggøre det stykke arbejde der er sat af til at skulle være færdig i dette sprint.

Man vil typisk altid have mange flere opgaver på ens product backlog end man kan nå at løse i et enkelt sprint, og man vil derfor skulle planlægge mange sprints i løbet af projektet. Men i slutningen af hver sprint afholder man det der hedder et Sprint review møde hvor man gennemgår det arbejde der er blevet lavet i dette sprint, og enten godkender eller afviser opgaverne.

Så i slutningen af hver sprint skal der altså helst være et konkret produkt, som kan leveres til kunderne og brugerne hvis de bliver godkendt. Der må helst ikke være nogle opgaver som ikke er klar til at blive leveret til brugeren. Hvis nogle opgaver er så store at man ikke kan få dem med i et normalt sprint kan man vente med at lancere dem for kunderne, og bundle 2-3 sprints sammen, men det er ikke ønskværdigt. Da det hurtigt skaber flaskehalse i projektet.

Hvornår startede man med at bruge Scrum?

Hele Scrum-tankegangen kan spores tilbage til en artikel i Harvard Business Review i 1986 som hed “The New New Product Development Game” af Takeuchi og Nonaka. Denne artikel beskriver hvordan virksomheder som Honda, Canon og Fuji-Xerox opnåede verdensklasse resultater, mens de samtidigt kunne skalere forretningen globalt uden at rende ind i flaskehalse.

De havde nemlig fokus på at give de enkelte medarbejder ret til at tage beslutninger selv, og lod tit projektgrupper organisere sig selv, frem for at have en person til at diktere det hele. Denne artikel startede hele forløbet som senere endte ud i at blive en konkret projektledelsesmetode, nemlig den vi kender som Scrum i dag.

Scrum er ikke en forkortelse for noget. Nej, det er faktisk et ord man har lånt fra sporten rugby. Her er det nemlig en specifik måde hvorpå man starter spillet igen efter et stop undervejs. Selvom du ikke har set rugby før, så ved du nok alligevel hvad en scrum er når du ser det. Det er nemlig når de to hold står overfor hinanden, tit hånd i hånd, med deres hoved nede, og hvor de banker sammen for at se hvilket hold der kan få fat på bolden.

Takeuchi og Nonaka brugte nemlig flere metaforer omkring rugby og scrum til at beskrive deres nye måde at udvikle produkter på i den artikel. De skriver for eksempel:

“The … relay race approach to product development … may conflict with the goals of maximum speed and flexibility. Instead a holistic or “rugby” approach – where a team tries to go the distance as a unit, passing the ball back and forth – may better serve today´s competitive requirements.”

Senere i 1993 tog Jeff Sutherland og videreudviklede deres teorier ind til det vi i dag kender som Scrum metoden. Og herfra tog det fart. Mange var hurtige til at adoptere den nye metode, og den blev de efterfølgende år videreudviklet til den metode som vi kender i dag. Selvom Scrum tit er brugt til IT og Digitale projekter, så er der intet til hindring for at bruge det til alle typer projekter. Der er mange eksempler på Scrum projekter som intet har med IT eller digital projekter at gøre, og der er meget få eksempler på projekter hvor det ikke giver mening at drive dem ud fra en Scrum tankegang.

Men hvorfor bruge Scrum metoden?

Scrum er et godt valg for virksomheder som befinder sig i det som hedder et Complex Domain , hvor der er en masse ubekendte, og hvor man løbene skal finde sin vej igennem projektet. Dette er ofte inden for brancher hvor man gerne vil være på forkant med teknologien og hele tiden innovere.

Grunden til at Scrum er god inden for disse brancher er at man ikke behøver en masse up-front planning, men at man i stedet bare kommer igang med at arbejde med metoden med det samme. Scrums fokus er derfor på at levere velfungerende, integreret, testet del-elementer af et større projekt, som både som en helhed, og for sig selv giver værdi til brugerne eller kunderne.

Hvornår skal man bruge Scrum?

Scrum fungere rigtig godt til de fleste projekter, men det er mere velegnet til nogle frem for andre. Herunder vil jeg kort gennemgå nogle af de kriterier der skal til for at Scrum passer til dig projekt.

Der er nemlig ifølge Cynefin frameworket, som er lavet for at hjælpe os til at forstå den kontekst som i arbejder indenfor, siger at der er fem forskellige domæner man arbejder inden for:

1. Obvious
2. Complicated
3. Chaotic
4. Complex
5. Disorder

Nedenfor vil jeg lige kort løbe dem alle igennem.

Complex Domain

Når man har med komplekse problemer at gøre, så er det tit fordi at de er uforudsigelige. Det er tid sådan, at hvis der er et “rigtigt” svar på en problemstilling, så vil du først vide det når du har forsøgt at løse problemet, der er nemlig tit ikke et åbenlyst svar.

Når man arbejder inden for dette domæne arbejder man derfor tit efter “Inspect & Adapt” tankegangen, hvor man løbende holder øje med det man laver, hvordan blev del-leverancen af projektet implementeret, og så retter man til undervejs i projektet. Scrum er en rigtig god metode inden for Complex Domains, da hele denne Inspect/Adapt tankegang er bygget ind i Scrum frameworket.

Complicated Domain

Complicated problemer er dem hvor der er en best practice som er domineret af eksperter inden for feltet man arbejder i. Der kan være flere svar som kan være “det rigtige” svar på projektet, men det er typisk kun eksperterne som kan regne ud hvilke der er de rigtige løsninger til problemerne. Her er Sigma Six metoden rigtig god, men man kan også sagtens bruge Scrum metoden til sådan problemstillinger.

Simple Domain

Når du har med simple problemstillinger, hvor alle kan se årsag og effekt af problemet og løsningen hedder det et Simple Domain. Disse er de nemme problemer, for der er altid en best practice, som man hurtigt kan Google sig frem til, eller hyre en konsulent ind til at fikse. Her kan Scrum også sagtens bruges, men der kan lige så vel bruges andre metoder.

Chaotic Domain

Når man har med kaotiske problemstillinger, som man skal reagere hurtigt på, så hedder det et Chaotic Domain. Dette er tit krisesituationer hvor man går i løsningsmode med det samme, hvor der ikke er tid til sprints, planlægning eller andet. Man skal bare have slukket en ildebrand. Så her bruger man sjældent en projektledelsesmetode, her er der bare en person som skal step up, og tage ansvaret for at koordinere folk på en måde hvor man kommer hurtigt i mål.

Disorder

Disorder er når du ikke ved hvilken af de andre domæner som du er en del af med dine opgaver, og det er et farligt sted at være. For så ved du ikke hvilket ben du står på, og kan ikke med sikkerhed sige hvad den rette vej frem er herfra. Så målet herfra er at finde ud af hvilket af de fire andre domæner er du i lige nu, og først derefter kan du finde ud af hvordan du skal gribe opgaven an.

Konklusion

Scrum er altså ikke en mirakelkur som passer til alle projekter. Men det er en super god metode når du har med Complex eller Complicated projekter, hvor fremtiden er lidt sløret. Det er tit sådan noget som IT projekter hvor det er meget brugt at bruge Scrum.