Derfor bruger vi Scrum

af Rasmus Klemmensen13. december 2018

Du har måske hørt ordet Scrum før, og du ved måske også, at Scrum har noget med "projektstyring" at gøre. Men hvad Scrum egentligt går ud på - ved du måske ikke helt. Det vil vi nu forsøge at gøre dig lidt klogere på i dette blogindlæg, hvor vi vil fortælle lidt om, hvordan vi bruger Scrum til at udvikle en af markedets bedste kommunikationsløsninger.

Du vil bl.a. høre lidt om historien bag Scrum, og hvordan vi benytter Scrum til dagligt. Derudover kommer vi med vores eget syn på, om Scrum altid er det bedste værktøj til projektstyring. Til sidst finder du en ordbog, hvor vi kort har beskrevet nogle af de mest gængse fagtermer i Scrum. 

Men lad os først starte med det noget besynderlige ord "Scrum". Det lyder lidt mærkværdigt, og der er formentligt mange, som har undret sig over ordet - måske lige bortset fra dem, der følger med i Rugby. I Rugby er Scrum der, hvor alle spillerne står i en stor cirkel og kæmper om bolden for dernæst at få den i mål. 

Man kan derfor drage en parallel til Scrum-værktøjet, der også er en metode til at få projektet tilbage i spil og dernæst i mål.

 

Historien bag Scrum
Scrum blev "skabt" i starten af 90'erne af Jeff Sutherland og Ken Schwaber, som præsenterede Scrum for offentligheden på en konference i USA. Skabelsen af Scrum skete på baggrund af et behov for en mere agil arbejdsmetode til at løse især IT-projekter, hvor de traditionelle vandfaldsmodeller ikke virkede optimalt. De hentede derfor (angiveligt) inspiration fra Toyota, der i 1988 beskrev The Toyota Production System, som dækker over begreberne: Lean eller just-in-time. Hovedpunkterne er i grove træk: Plan, Do, Check, Act - hvilket grundlæggende er den cyklus, som man arbejder ud fra i Scrum. 

 

Hvorfor er Scrum blevet så populært?
Scrum er blevet rigtig populært, fordi metoden har vist sig at være god til at give hurtige og værdiskabende resultater. Det er nok især IT-virksomheder, der har nydt godt af Scrum som et effektivt værktøj til komplicerede projekter. Derfor har mange IT-virksomheder kastet sig ud i brugen af Scrum, da Scrum ligeledes er forholdsvis nemt at gå til og meget håndgribeligt at arbejde efter. Det er dog ikke ensbetydende med, at man fra dag ét kan få fuldt udbytte af Scrum, da det godt kan tage et par års øvelse at forstå kernen i Scrum.

Vi har nu arbejdet med Scrum i mere end 6 år, hvilket har givet os en god forståelse af Scrum, og samtidig gjort os i stand til at optimere processen endnu mere, så Scrum i endnu højere grad passer til vores forretning.

 

 

Så hvad går Scrum ud på, og hvordan bruger Flexfone det?
Scrum er kort fortalt en agil arbejdsmetode, hvis formål er at hjælpe med udviklingen af løsninger til komplekse problemstillinger. Scrum stiller et framework til rådighed, der består af et sæt roller, teknikker og arbejdsprocesser, som tilsammen gør det muligt for udviklingsteams at levere de bedste løsninger til kunderne. 

En af fordelene ved Scrum er, at vi kan få hurtige resultater, selvom der løbende opleves skiftende behov. Scrums framework gør det nemlig muligt for os at foretage løbende justeringer og prioriteringer. Det kan bl.a. lade sig gøre, fordi der er fleksible tidsplaner, små udviklingshold, hyppig gennemgang og et stærkt samarbejde mellem de forskellige udviklingsteams.

Fleksibiliteten skal dog placeres i nogle faste rammer, som skal være med til at styre og strukturere arbejdet. Nedenfor ses vores arbejdsproces i en simplificeret form, som hvert af vores udviklingsteams arbejder igennem og dernæst starter forfra, hvilket kaldes for en iterativ arbejdsproces - altså noget som gentages om og om igen.  
 

En arbejdscyklus er bygget op af forskellige moduler, som hver især tjener et værdifuldt formål. I vores cyklus arbejdes der med en periode på 10 arbejdsdage (14 dage). Denne periode kan for nogle være for lang og andre for kort. Man bestemmer derfor selv længden af en cyklus, men det vigtige er, at man fastholder længden, så det ikke skifter løbende alt efter mængden af projekter/opgaver mv. Vi har tidligere leget med andre intervaller, men 10 dage er dét, som passer bedste til os. 

Af de fire moduler er det såkaldte sprint nok det vigtigste. Det er nemlig der, hvor udviklerne arbejder på de projekter og opgaver, som de har været med til at planlægge. De tre andre moduler er skam også vigtige, da de støtter op om det arbejde, der udføres i et sprint.  

 

Sådan bruger vi Planning
Det giver nok sig selv, at man ikke kommer uden om en vis form for planlægning. En fordel ved Scrum er, af planlægningen sker løbende, og udviklerne er selv med til at planlægge deres arbejde.

For at planlægningen kan forløbe så nemt og effektivt som muligt, er der i løbet af det tidligere sprint brugt én time på et såkaldt refinement møde. Det er en session, hvor teamet får mulighed for at vurdere kompleksiteten og ressourcebehovet af et antal opgaver, som ligger i opgavekartoteket (Backloggen). Disse opgaver er prioriteret af den produktansvarlige (Product Owner eller PO), som har til ansvar at holde backloggen opdateret med de vigtigste opgaver. 

For at gøre vurderingen af hver opgave mere håndgribelig tager vi udgangspunkt i storypoints som en form for valuta for at synliggøre kompleksiteten og ressourcebehovet ved en given opgave. Når vi så skal planlægge næste sprint, vurderer teamet, hvor mange af disse opgaver med tilhørende storypoints, de kan klare i løbet af det kommende sprint. Vores PO har på forhånd vurderet et estimat ud fra gennemsnittet af storypoints, som er løst i de sidste 8 sprints. Dette holdes så op imod det komme sprint og de ressourcer, der er til rådighed (ferie, fridage, sygdom). Selve planlægningen forløber over to omgange med Planning 1 & 2. Ved Planning 1 vælges et antal opgaver med storypoints, som matcher de ressourcer, der er til rådighed. Dernæst afholdes der Planning 2, hvor hver opgave tidsestimeres, så der ligger en helt klar plan for det kommende sprint, som teamet kan give håndslag på. 

 


 

Det er dog ikke altid, at det ender med at passe i slutningen af et sprint. I nogle sprint kan der være opgaver, som ikke er nået, da fx kompleksiteten har været højere end forventet. Derfor er det nogle gange nødvendigt, at vores PO trækker opgaver ud af et sprint, hvis forudsætningerne ændres sig. Det kan også være, at man i løbet af et sprint får løst opgaverne hurtigere end ventet, og teamet kan sammen med PO'en omprioritere og muligvis trække flere opgaver ind i det pågældende sprint.  

 

Forløbet under et Sprint
Når planlægningsmødet så er afsluttet, kan hvert team påbegynde sprintet. I løbet af et sprint holdes der dagligt et møde (Daily Scrum), hvor hvert team mødes og gennemgår de opgaver, som de har arbejdet på dagen før, og de opgaver, der skal arbejdes på indtil mødet dagen efter. Hensigten med Daily Scrum er at holde teamet opdateret og være med til at koordinere opgaver for de næste 24 timer. Dermed kan man i højere grad sikre den rette progression i løbet af et sprint.

Som en hjælp til at holde fokus på de rette ting til et Daily Scrum, kan følgende tre spørgsmål besvares af hver medarbejder: 

- Hvad opnåede du dagen før?
- Hvad skal du arbejde på indtil næste møde?
- Hvad ligger der i vejen for, at du kan løse dine opgaver?

Det er en Scrum Master, der faciliterer de daglige møder. Til et Daily Scrum er det vigtigt, at det er teamet, som gennemfører mødet. Scrum Master er kun med for at guide og sørge for, at mødet holdes kort og efter hensigten. Og der skal være en Scrum Master til stede ved hvert Daily Scrum, hvilket ofte er en af medarbejderne fra et andet team, som har den faste rolle som Scrum Master.

 

Vi præsenterer og bliver klogere med Review og Retrospective
Efter hvert sprint afholdes der en præsentation (Sprint Review), hvor hvert team præsenterer dét, de har løst i løbet af sprintet, og hvad teamet evt. ikke fik løst. Dette efterfølges af et evalueringsmøde (Retrospective), hvor fokus er på at evaluere sprintet - hvad gik godt? hvad kunne være gjort bedre? osv... Efter et retrospective udfærdiges der nogle "Items", som placeres som opgaver i det kommende Sprint. Disse items skal være med til at sikre, at evalueringen af det forgangne sprint får en positiv indvirkning i det næste. 

 

Product Owner lægger strategien
En Product Owner (PO) er personen, der har til ansvar at prioritere og vedligeholde backloggen, Sprintplanlægningen og i visse tilfælde gennemføre Sprint Review. Product Owner er den eneste person, der er ansvarlig for administration af backloggen, hvilket omfatter: 

  • Forståelige opgaver i backloggen
  • Prioritering af opgaver i backloggen
  • Sikring, at backloggen er synlig, transparent og klar for alle

For at kunne udfylde rollen som PO bedst muligt kræves der to vigtige egenskaber - klar kommunikation og god prioritering. PO'en skal kunne kommunikere gældende behov til udviklerne og på den anden side formidle de udviklede løsninger over for kunderne og interessenter.   

Prioritering er afgørende i den forstand, at de forskellige teams skal udvikle de "rigtige" løsninger, som matcher eller overstiger kundernes forventninger. Prioriteringen skal også tage højde for andre interessenter, organisationens kapaciteter, overordnede mål for virksomheden osv. 

Vores PO har ansvaret for tre forskellige teams, som arbejder på hver deres opgaver, men hvor mange af opgaverne hænger sammen. Derfor ligger der et stort arbejde i at koordinere arbejdet imellem de forskellige teams, så de overordnede projekter kommer i mål. Det er forskelligt fra virksomhed til virksomhed, om man bruger en eller flere PO'ere i en organisation. Det kommer ofte an på, hvor stor udviklingsafdelingen er, og om der arbejdes på få eller mange forskellige projekter. 

 

Skal alle elementer af Scrum altid bruges?
Nej, det står alle frit for at justere frameworket, så det passer bedst muligt til den pågældende organisation. Vi benytter fx ikke et Product Roadmap og en Releaseplan, fordi vi har fundet ud af, at vi er mere agile uden. Vi er dermed mere fleksible i vores udviklingsarbejde og kan hurtigere ændre kurs, hvis det er nødvendigt. Ligeledes kan vi også hurtigere lancere nye produkter, fordi vi gør det så snart det er færdigudviklet, hvilket giver mest værdi til vores kunder. 

Det kan være svært at vide på forhånd, om alle elementer giver mening eller ej, før man er begyndt at bruge Scrum. Derfor vil det i de fleste tilfælde være en god idé at tage udgangspunkt i alle elementer af Scrum, hvorefter man løbende kan justere, hvis det passer bedre til ens organisation. 

 

Er Scrum altid det rigtige at bruge?
Nej, det ville være naivt og utroværdigt, hvis vi påstod, at Scrum altid er den rigtige approach til projekter. Der er da også steder i Scrum metodikken, hvor der kan opleves visse udfordringer. Det kan bl.a. være rapporteringen opad til f.eks. den styregruppe, som de fleste virksomheder foretrækker at bibeholde for at bevare kontrollen på lederniveau. Scrum forudsætter også, at Product Owner og Scrum Master håndterer interessenter og varetager kommunikationen ud af projektet, hvor metode til dette ikke er defineret i Scrum. Disse opgaver kan man ikke bare se bort fra, og derfor kan man med fordel kombinere Scrum med PRINCE2. Derudover kommer det også meget an på, om projekter er af kendt eller ukendt karakter...

Projekter af kendt karakter
Arbejder man med projekter, hvor rammerne er kendte, hvor tiden er afgørende, og hvor der er et højt krav til, at samspillet mellem komponenter altid fungerer, er Scrum ikke nødvendigvis den rette metode at bruge. Scrum er i højere grad værdiskabende ved projekter, hvor rammerne er mere ukendte og kompleksiteten er høj. 

Eksempel: 
Ønsker man som kunde at få udviklet et IT-system, som kan dét og dét, kan det være meget svært at bruge vandfaldsmodellen, da det er svært at vurdere ressourcebehovet på forhånd. Derudover er det heller ikke sikkert, at kunden fra start er helt klar over, hvordan systemet skal fungere. Derfor skal der være plads til, at man undervejs har en dialog med kunden, så man kan justere eller ændre kurs, hvis ikke der udvikles det "rigtige".

 

Opsummering
Nu er du kommet igennem blogindlægget, og jeg håber, at du sidder med en nogenlunde forståelse af, hvad Scrum går ud på. Det kan måske virke lidt indviklede, så her får du lige en kort opsummering...

Scrum er udviklet i starten af 90'erne som et agilt framework til at udvikle løsninger, som ofte er af softwaremæssig karakter. Mange virksomheder er allerede i gang med at bruge Scrum og flere kommer løbende til. Scrum består overordnet af nogle faste rammer som man selv definere, og de rammer er som regel lagt ind i kortere tidsintervaller. Hos Flexfone er dette tidsinterval 10 arbejdsdage, hvor de 9 dage er selve sprintet. I sprintet løses der en forudbestemt mængde opgaver, som teamet selv har været med til at bestemme. Når sprintet er slut, præsenteres løsningerne for Product Owner og andre interessenter. Dernæst afholdes der et Retrospective, hvor teamet gennemgår processen af det netop gennemførte Sprint for at blive klogere/bedre. 

En af fordelene ved Scrum er den løbende dialog, planlægning og prioritering, som er med til at sikre, at teamet altid arbejder på de mest relevante opgaver. 

Scrum er ikke nødvendigvis den bedste metode at bruge til alle typer af projekter. Scrum gør sig bedst gældende ved mere komplekse opgaver, hvor der er flere ubekendte faktorer. Ved kendte opgaver og projekter kan det være en fordel at bruge de mere klassiske vandfaldsmodeller, hvor de fleste ting kan planlægges på forhånd. 

Vær opmærksom på, at det er helt op til den enkelte virksomhed, hvordan de ønsker at strukturere de forskellige elementer i Scrum. Vi har blot refereret til nogle af de ting, som vi har fundet ud af, fungerer godt for os. 

________

Jeg håber, at du har fået noget ud af at læse med, og har du lyst til at lære mere om Scrum og måske overvejer at implementere det i din virksomhed, så kan vi anbefale, at du besøger disse hjemmesider og henter mere information:

https://www.scrum.org/

https://www.teknologisk.dk/

https://www.agile42.com/en/