Scrum---et-enkelt-rammeverk-for-komplekst-arbeid

Scrum - et enkelt rammeverk for komplekst arbeid

Skrevet av Jonas Högstrand - 29. mai 2019

Scrum oppstod som svar på den såkalte fossefallsmodellen, der alle aktiviteter avhenger av noe forutgående. Fossefallsprosjekter krever detaljert planlegging og komplekse arbeidsflyter. På 1990-tallet var det trolig årsaken til en rekke prosjektkatastrofer i IT-verdenen. Noen mente at metoden ble brukt feil. Andre mente at det var behov for enda mer detaljert planlegging.

Jeff Sutherland og Ken Schwaber gikk motsatt vei og skapte en fleksibel arbeidsmodell i form av Scrum.

Scrum forutsetter at man arbeider i små, selvstendige, tverrfaglige team. I stedet for langsiktig planlegging benytter Scrum korte iterasjoner, løpende kontroll av resultater og gradvis tilpasning av den overordnede planen. Det hele foregår fullstendig transparent og med vekt på felles forståelse for mål og prosess.

LES OGSÅ: Dette er de smidige rammeverkene

Scrum-team med forskjellige roller

Scrum muliggjør komplekst arbeid gjennom enkle prosesser. Det klassiske Scrum-teamet er inndelt i ulike roller.

En produkteier (Product Owner) representerer kunden/brukeren og prioriterer oppgavene som skal utføres.

Et utviklingsteam (Development Team) på 5–9 personer har de nødvendige ferdighetene til å utvikle det ferdige produktet.

Til slutt har vi en Scrum-leder (Scrum Master) som har ansvaret for at alle i teamet forstår og bruker Scrum riktig.

Ta en titt på vårt blogginnlegg om roller og ansvar i scrum-prosjekter dersom du ønsker å lære mer om rollene i et Scrum-prosjekt og ansvaret som følger med.

Tidsbokser og sprinter

I Scrum arbeider man innenfor såkalte tidsbokser. En produkteier har en ønskeliste over nye funksjoner, kalt en produktkø (Product Backlog). Ingen vet hvor lang tid det tar å utvikle alle funksjonene, og det er heller ikke interessant.


Gratis e-bok: Få et overblikk over smidige metoder på team-, prosjekt- og  bedriftsnivå.


Scrum-teamet avtaler en overordnet tidsboks på for eksempel seks måneder, der neste release skal ferdigstilles. Disse seks månedene deles så inn i kortere tidsbokser, såkalte sprinter, på for eksempel to uker.

Når første sprint starter, foretar teamet en sprintplanlegging der de velger de høyest prioriterte oppgavene som realistisk sett kan leveres i løpet av to uker. Disse ønskene legges i sprintkøen (Sprint Backlog). Deretter får utviklingsteamet fullstendig ro. Det er ingen nye krav og ingen forstyrrelser.

Daily Scrum, Backlog og Retrospective

Utviklingsteamet møtes hver dag til et kort Scrum-møte (Daily Scrum), der alle teammedlemmene redegjør for gårsdagens aktiviteter, dagens aktiviteter og eventuelle utfordringer som står i veien for arbeidet. Det daglige Scrum-møtet gir teamet felles ansvar for ferdigstillelsen av flest mulig oppgaver.

På sprintens siste dag møtes Scrum-teamet til en sprintgjennomgang (Sprint Review) der utviklingsteamet fremviser den nye funksjonaliteten. Alt som vises frem, skal være testet, dokumentert og helt ferdigutviklet. Delvis utviklede produkter er uinteressante.

Produkteieren forholder seg til leveransen og skisserer nye ønsker i en produktkø (Product Backlog). Deretter evaluerer utviklingsteamet den ferdige sprinten i et såkalt retrospekt (Retrospective) som blant annet skal komme med forslag til fremoverrettede forbedringer. Videre starter prosessen forfra i en ny iterasjon/sprint.

Omfanget av den planlagte seks måneders releasen bør ikke estimeres i forkant av første sprint. Det er først mulig å foreta realistiske estimater etter en eller to sprinter. Da blir prognosene sikrere, og man unngår å kaste bort tid på spesifikasjoner og estimater for oppgaver som likevel ikke skal utføres fordi prioritetene har endret seg.

Hva passer Scrum til?

Scrum er ikke svaret på alt. Det er for eksempel verken en prosjektstyringsmodell eller en metode for løpende drift.

Scrum er utviklet for bruk i eksisterende organisasjoner (for eksempel en prosjektorganisasjon eller linjeorganisasjon). Metoden har ingen prosjektlederrolle ettersom den utelukkende fokuserer på leveranseteamet.

Scrum kan fungere uten prosjektleder, men ikke uten en ledelsesstruktur. Den kan sammenlignes med spillsystemer i fotball. Selv om det ikke er behov for en administrerende direktør til 4-4-2-systemet, er det likevel behov for en trener og en direktør i klubben.

LES OGSÅ: Kanban eller Scrum?

Fakta om Scrum

Oppbygning

Scrum består av tre roller, fem hendelser og tre artefakter.

  • Roller: Produkteier (Product Owner), utviklingsteam (Development Team) og Scrum-leder (Scrum Master)
  • Hendelser: Sprint, sprintplanlegging (Sprint Planning), daglig Scrum-møte (Daily Scrum), sprintgjennomgang (Sprint Review) og sprintretrospekt (Sprint Retrospective)
  • Artefakter: Produktkø (Product Backlog), sprintkø (Sprint Backlog) og inkrement (Increment)

Kjennetegn

Et Scrum-team er:

  • Selvorganisert
  • Samlokalisert
  • Tverrfaglig (kan håndtere alle oppgaver fra idé til ferdig produkt)
  • Lite: 5 personer (+/- 2)
  • Stabilt over tid (de samme personene arbeider sammen uten faktisk sluttdato)

Målgruppe

Scrum er blitt de facto-standarden for smidig utvikling i mange offentlige og private virksomheter. Metoden krever et multifunksjonelt fulltidsteam med en dedikert Scrum-leder og en seriøs produkteier.

Hvis man går på akkord med metodikken, risikerer man at den forventede verdien ikke blir realisert. Implementering av Scrum krever full tillit.

Bruk

Scrum brukes primært ved programvareutvikling, men har også spredt seg til andre former for produktutvikling.

Utbredelse

Størstedelen av all programvareutvikling involverer Scrum.

Sertifisering

Scrum er ikke en beskyttet tittel. Alle kan tilby sertifiseringer. Vær oppmerksom ved valg av tilbyder. Kvaliteten og verdien på sertifiseringen kan variere fra sted til sted. Scrum Alliance og Scrum.org er de to mest anerkjente tilbyderne. Begge tilbyr sertifiseringer for en rekke roller, blant annet Certified Scrum Master (CSM) og Professional Scrum Master (PSM).

Nivå

Scrum brukes på teamnivå.

Beskrivelsesgrad

Lav

Det smidige landskapet kan være en jungel hvis du ikke kjenner mulighetene på forhånd. Last ned vår e-bok gratis for å få en oversikt over fordeler og ulemper ved de mest brukte smidige metodene.

New call-to-action

Temaer: Smidige metoder


Jonas Högstrand

Skrevet av Jonas Högstrand

Jonas har mer enn 16 års praktisk erfaring som prosjektleder, konsulent og rådgiver i private og offentlige virksomheter i Danmark, Sverige, England og Tyskland. Blant kundene hans er Leo Pharma, PostNord, Rambøll Informatik, ISS, Novozymes m.fl. Hans spesielle fokusområder er smidigcoaching og utvikling av kundespesifikke prosjektmodeller basert på henholdsvis PRINCE2® og smidige prosjektledelsesmetoder, design av prosjektakademier og gjennomføring av modenhetsvurderinger. Jonas er instruktør, smidigcoach og seniorrådgiver innen prosjektledelse. Han er sertifisert instruktør i PRINCE2®, PRINCE2 Agile® og SAFe® samt sertifisert P3M3® Assessor, og har vært kvalitetskontrollør for den offisielle PRINCE2 Agile®-veiledningen.

Mest leste artikler