Introduktion til Scrum

Scrum er en agil metode (blandt flere fx Kanban, Featuredriven Development, Lean Development,….), som hviler på et sæt af agile principper.

Den agile fremgangsmåde er baseret på en trinvis og iterativ tilgang. I den agile metode opfattes en iteration som en projektcyklus i miniformat, hvor et tværorganisatorisk team på baggrund af en liste med prioriterede behov og krav, designer og udvikler elementer, som er testet og klar til at indgå som del af den færdige løsning.

Overordnet er gennemførelse af et projekt – efter den agile metode – et projekt, som foregår i forholdsvis korte udviklingstrin, såkaldte iterationer hvis typiske længde er 2-4 uger. Udvikling i iterationer står dog ikke i sig selv i modsætning til de klassiske udviklingsmetoder efter vandfaldsmodellen, hvor iterationer også kan indgå som en naturlig del af udviklingsprocessen.

Listen over prioriterede behov og krav ”ejes” af en repræsentant fra forretningen (Product Owner) og Scrum teamet udvikler de elementer med højest prioritet, således at dét, der efterspørges som det vigtigste, udvikles først. Når en iteration er færdig, genprioriterer Product Owner listen med behov og krav med henblik på, at Scrum teamet kan tage fat på en ny iteration, hvor det igen er de vigtigste behov og krav, der søges opfyldt.

Projekttrekanten og Scrum
Projektrekanten i den traditionelle vandfaldsmodel tager i de fleste tilfælde udgangspunkt i Scope indholdet, hvorefter der med udgangspunkt i et antal ressourcer fastlægges et tidspunkt for færdiggørelse. Alternativt er deadline fast og antal ressourcer for at møde deadline fastsættes. I nogle tilfælde arbejdes der også med en reduktion af Scope på grund af begrænsninger i deadline og antal ressourcer.

Den Agile tanke hviler mere på at levere det, som giver mest værdi først og altid i den rette kvalitet. Det vil sige at test og godkendelse er en integreret del af hver iteration. Scope, Ressourcer og Tid anses som begrænsninger. Scope prioriteres efter værdi (listen af prioriterede behov) og Scope kendes ikke i samme detaljeomfang som i den traditionelle vandfoldsmodel med en fuld specifikation. De enkelte krav i Scrum beskrives detaljeret inden igangsættelsen af en iteration (Scrum Sprint).

Forberedelsen inden et Sprint – 3 elementer
I Scrum er der en forberedelse som kan inddeles i 3 elementer (Produkt vision, Produkt Roadmap, Releaseplan)

1. 1. Udarbejdelse af en Produkt Vision.
      Produkt visionen er det overordnede styrende elementer for hvad der skal leveres. Fx ”Vi vil bygge en e-handels portal for salg af økologiske grøntsager til unge mellem 20-25 år.”
      Produkt visionen er styrende for om forslag til features/funktionalitet er en del af Scope og alle forslag skal falde inden for visionens rammer.

 

1. 1. Produkt Roadmap
      Produkt Roadmap er en nedbrydning af produkt visionen i delløsninger og overordnet beskrivelse hvilke features/funktioner der haves i hver enkelt delløsning. Her beskrives desuden hvilken værdi den enkelte delløsning forventes at skabe.

 

1. 1. Releaseplan

Releaseplanen er en yderligere nedbrydning af hvert element i roadmappen. I Scrum fokuseres på at Release 1 skal være et Minimum Viable Product = MVP. Dette medfører at Release 1 er begrænset til at absolut minimum for at være fungerende. For hver release beskrives hvile Features/funktioner delløsningen indeholder. I vores eksempel med portalen vil MVP indeholde en betalingsfunktion – men betalingsfunktionen kan i MVP være begrænset til betaling med Dankort. Andre kort kan komme i en senere release samt muligheden for at betale med mobile pay.

Tankegangen bag ved releaseplanen er, at brugerne ikke altid ved hvad de vil have og jo mere de anvender løsningen Release 1) jo bedre vil de være til at stille krav. Ligeledes er det en reduktion af risici da det måske kan vise sig at løsningen ikke kan laves eller brugerne ikke vil anvende løsningen.

Scrum – eksekvering i sprint.

I scrum kaldes en iteration et Sprint. Sprintet kan være fra 1-6 uger og de fleste vælger at være mellem 2-4 uger.

Tre artefakter i Scrum
I Scrum haves artefakter som er:

1. Product Backlog
   Product Backlog (liste med prioriterede krav/behov)
2. Sprint Backlog
   Sprint Backlog som er en delmængde af arbejde fra Product Backlog og som teamet leverer efter et Sprint.
3. Burn Down Chart
   Burn Down Chart som er en visuel gengivelse af hvor meget arbejde teamet mangler i at være færdige.

Tre roller i Scrum

1. Scrum Team
   Ofte er det et tværorganisatorisk team af udviklere, frontend desigenere og testere som sikrer at krav fra Produkt Backlog (4) leveres efter hvert sprint.
2. Product Owner
   Product Owner som er en repræsentant fra forretningen, hvis opgave det er at vedligeholde backloggen med krav der er klar til udvikling, hjælper Scrum Teamet med at løse eventuelle problemer og sikrer at der foreligger en godkendelse af Teamets arbejde i Sprint Review/Demo (7)
3. Scrum Master
   Scrum Master er en neutral facilitato,r der skal sikre at alle aktiviteter afholdes. Scrum Master planlægger og indkalder til alle møder samt facilitere agendaen på disse møder.

Sprint-aktiviteter

I hvert sprint foregår følgende aktiviteter/møder.

• Vedligeholdelse af Product Backlog
  Product Backlog er listen med de prioriterede krav. Hvert krav er beskrevet som en User Story (yderligere beskrivelse af User story er ikke medtaget i denne artikel). I Scrum varetages vedligeholdelsen af en Product Owner (repræsentant fra forretningen). Product Owners opgave er at sikre backloggen løbende gøres klar til de enkelte sprint (kaldes Grooming). I praksis vil Product Owner samarbejde med andre brugere i forretningen og/eller Scrum Teamet om klargøring.
• Sprint Planlægning
  Scrum Master indkalder og facilitere dette møde. Product Owner har til opgave at udtage en delmængde af opgaver til leverance i sprintet. Planlægningsmødet er opdelt i 2 dele:Del 1 – Her gennemgår Product Owner de opgaver som SCRUM teamet skal løse, Scrum Temaet spørger ind til opgaverne for at sikre den endelige forståelse. Opgaver som for Scrum Teamet virker uklare kan afvises af teamet med ønsket om yderligere modning.Del 2 – Her tager Scrum Teamet hver enkelt opgave og nedbryder disse i Tasks. En task er et mindre stykke arbejder som en eller flere sammen skal gennemføre som en del af leverancen. Hver task estimeres i timer. Nedbrydning i tasks over 18 timer anbefales ikke da opgaven derved kan indeholde for mange usikkerhedsmomenter.
• Stand Up møde
  Efter sprint planlægningen går SCRUM teamet i gang med opgaverne og der afholdes dagligt et Stand Up møde. Stand Up mødet har til formål at teamet deler viden om fremdrift på de enkelte opgaver. Eventuelle blokeringer i arbejdet deles også. Her er det Scrum Master’s ansvar at byde sig til for at hjælpe med at fjerne blokeringer i arbejdet.
• Review møde
  Ved afslutningen Sprintet afholdes et Review mødet. Formålet med Reviewmødet er at Scrum Teamet gennemgår / demonstrerer deres løsning og Product Owner godkender leverancen.Eventuelle opgaver der ikke er afsluttet eller ikke godkendes overføres til Product Backlog og Product Owner prioriterer om disse skal med i det næste sprint eller nedprioriteres.
• Retrospektive
  Det sidste møde i Scrum er Retrospektive. Retrospektive er en væsentlig del af Scrum da Teamet skal dele viden og erfaringer om hvad gik godt og hvad der ønskes ændret på i arbejdet. Retropsektive er en del af ”Kontinuerlig forbedring” og skal sikre at teamet øger deres produktivitet gennem højere hastighed og forbedret kvalitet.

Afslutning
Scrum er den mest udbredte af de agile metoder – men Scrum er ikke velegnet til alt. Scrum fungere bedst når hele teamet kun arbejder på et projekt af gangen. Jeg har set eksempler på at et Scrum Team har arbejdet samtidigt på flere projektet i et sprint. Dette medfører også at teamet ikke kan se værdien af Stand Up møder – da videndeling på tværs af flere projekter ikke giver mening, Review og demo møder giver heller ikke mening da flere interessenter nu skal involveres.
Såfremt et team skal arbejde med flere projekter ad gangen anbefales Kanban modellen som er mindre rigid med hensyn til møder og regler.

Scrum er en ikke en projektmodel.
Scrum er en model til strukturelt at levere leverancer – en leverancemodel. Det er absolut ikke en projektledelses model da Scrum ikke indeholder ressourcestyring, omkostningsstyring, stakeholder management m.m. I nedenstående figur er det illustreret hvordan Scrum skal anses som leveranceledelse.

Er Scrum det nye vidunder og skal vandfaldsmodellen udfases?
Scrum har absolut mange fordele men kan ikke nødvendigvis anvendes til alle typer af projekter.

Vandfaldsmodellen har absolut stadigvæk sin berettigelse. Scrum modellen bør f.eks. ikke anvendes ved projekter hvor omkostninger til forandring af det allerede byggede er store. Dette gælder f.eks. byggeri hvor Scrum i sin tilgang kun vil være baseret på kun at bygge en del af fundamentet og efterfølgende ændre fundamentet hvis der opstår nye behov. Dette vil være omkostningstungt og tidskrævende.

Dog kan sprint tankegangen fint anvendes til at levere en samlet leverance der hedder fundamentet men alle krav til fundamentet skal være kendt først.