Et eksempel på et prosjekt der scrum-metoden kommer godt med er hvis du for eksempel skal bygge en bro. Når du bygger en bro er det nemlig lurt å innhente nok informasjon i forkant til å kunne gjennomføre prosjektet på en fastsatt måte. Brukerens behov og atferdsmønster er ikke preget av radikale endringer eller nye trender – brukeren skal kjøre over broen for å komme seg fra A til B, og det er det.
Materialenes levetid er forholdsvis konstant og kan planlegges for, vindhastighet kan tas høyde for, og så videre. Brobyggingsprosjekter har mer eller mindre konstante parametre som vi vet om på forhånd og kan planlegge for.
Tar vi dette tilbake til IT-verden, så har som oftest ikke IT-prosjekter denne luksusen. Med det menes at det er relativt få reelle konstanter, og det kan skje veldig mye i løpet av prosjektets levetid som er vanskelig å forutse: Brukerens behov, atferdsmønster eller interesser kan ha endret seg.
Rammeverkene og teknologiene du bruker for å bygge løsningen er i stadig endring. En annen aktør kan lansere en konkurrerende løsning. Endringer i personvernlovgivningen krever nye funksjoner for sletting, endring og mulighet for begrenset behandling av enkelte typer data (*kremt* GDPR *kremt*). Hvis du planla ferdig hele prosjektet ditt i fjor og noe av dette skjer, har du et kjempeproblem nå.
Så hvordan går vi frem for å utvikle store og komplekse IT-løsninger når det er så mange ukjente variabler? Vi bruker en gjennomføringsmodell som ikke bare baker inn at det finnes en viss risiko, men som har endringshåndtering som kjerne. Et av de mest brukte rammeverkene er Scrum.
Hva er egentlig Scrum?
Scrum er et smidig prosessrammeverk utviklet for å støtte kompleks produktutvikling. Det er basert på empirisme, altså at kunnskap kommer fra erfaring og beslutninger som baseres på det som er kjent. Scrum er det ledende rammeverket for programvareutvikling, men det kan også være nyttig i andre sammenhenger.
Scrum består av tre grunnleggende roller, som til sammen utgjør et Scrum-team:
- Produkteieren, som oftest kunden, bestemmer hva produktet skal være. Produkteieren prioriterer hvilke funksjoner som skal utvikles til enhver tid, og jobber sammen med teamet for å detaljere funksjonliteten og lage akseptansekriterier. Dette arbeidet gjøres i en “product backlog” – en prioritert og estimert liste over funksjonalitet. Produkteieren er typisk en person som har mye dybdekunnskap om forretningsområdet, kjenner brukernes behov godt og har beslutningsevne og myndighet til å prioritere både etter funksjonalitet og budsjett.
- Utviklingsteamet bygger produktet i henhold til produkteierens prioritering. Teamet skal være selvorganiserende – de bestemmer selv hvordan de ønsker å organisere eget arbeid og alle er gjensidig ansvarlige for å levere funksjonaliteten som er bestilt. Utviklingsteamets størrelse er normalt sett på mellom 5 og 9 personer – mange nok til å levere et signifikant stykke arbeid, men få nok til å være fleksible. Teamet er optimalt sett tverrfaglig nok til å klare å levere et produkt helt ut i produksjon, og inkluderer fortrinnvis kompetanse på både design, programvareutvikling, kvalitetssikring og bygg og miljø.
- Scrum masteren sørger for at scrum-teamet etterlever Scrum-teorien. Dette gjøres blant annet ved å være en coach og sparringspartner, fasilitere for god kommunikasjon og planlegging, fjerne hindringer underveis, skjerme utviklingsteamet for distraksjoner og ytre press og tilrettelegge for transparente prosesser mellom utviklingsteam og produkteier. Scrum masteren har ingen formell myndighet, men fungerer som en “servant leader” som sørger for at alle har det de trenger for å utføre arbeidet sitt på en effektiv måte.
Har du lyst til å jobbe i et fremoverlent miljø med moderne teknologi?
Slik gjennomfører man
Selve prosjektet gjennomføres på en inkrementell måte. Man starter med den viktigste og mest grunnleggende funksjonaliteten (altså den funksjonaliteten produkteier prioriterer høyest), og bygger deretter på mer og mer funksjonalitet. På denne måten maksimerer man hele tiden produktets verdi, og man får korte “feedback loops” – man får løpende tilbakemelding på hva som fungerer og ikke fungerer, og kan justere underveis.
Dette gjøres i såkalte “sprinter” – en fast leveransesyklus på èn til fire uker. I løpet av sprinten skal man planlegge og utvikle neste inkrement (eller versjon) av produktet, demonstrere funksjonaliteten for prosjektets interessenter og deretter gjøre en evaluering og iverksette forbedringstiltak.
Les mer: Hvorfor bruke en konsulent som prosjektleder til digitaliseringen
Slik fungerer sprintsyklusen
En sprint starter med planleggingsmøtet, hvor scrum-teamet fastsetter hva som skal leveres i løpet av sprinten og hvordan. Hver bit av funksjonaliteten gjennomgås sammen med produkteier slik at hele utviklingsteamet har en god forståelse av både behov og målsetning, og detaljeres deretter ned til konkrete arbeidsoppgaver. Resultatet av møtet er et overordnet mål for sprinten og sprint-backloggen – alle oppgavene som skal gjennomføres i sprinten – typisk representert som lapper på en tavle med kolonner for “to do”, “doing” og “done”.
Les mer: Hvordan lykkes med strategiimplementering?
I løpet av sprinten gjennomføres arbeidet. Hvert medlem i utviklingsteamet velger en oppgave, gjennomfører den og setter den til “ferdig”. Typisk er flere involvert i samme oppgave for å kvalitetssikre arbeidet underveis. Hver dag holdes et kort statusmøte for å se hva som er gjort, hva som skal gjøres, og hvilke eventuelle hindringer man har for å nå sprintmålet. På denne måten opprettholdes transparent kommunikasjon, alle er oppdatert på status, man får identifisert hindringer tidlig og kan ta raske beslutninger underveis.
På slutten av sprinten holdes et Sprint Review sammen med Scrum teamet og eventuelle interessenter. Her ser man på det som har blitt levert i løpet av sprinten og får tilbakemeldinger og innspill. Dette fører ofte til at man oppdager nye oppgaver, og man diskuterer i fellesskap hva neste sprint skal inneholde for å maksimere produktverdien.
Det siste som skjer i sprinten er Sprint Retrospektiv. Her tar teamet et tilbakeblikk på sprinten som har vært, og identifiserer hva som har gått bra, og hva som kunne ha gått bedre. Man kommer så frem til en tiltaksplan for å forbedre måten man jobber på.
Hvorfor velge Scrum?
Scrum gjør det mulig å fokusere på små, konkrete oppgaver, mens man hele tiden har det «store bildet» klart i sikte. På denne måten hjelper Scrum med å skape akkurat nok struktur til at teamet kan fokusere sin innovasjon på å løse noe som ellers kan virke som en uoverkommelig oppgave. Med et tverrfunksjonelt og selvorganiserende team, har teamet selv mulighet til å utføre alt arbeidet som kreves for å levere et ferdig produkt, og vil til enhver tid kunne organisere seg slik at det blir utført på den mest effektive måten. Når man i tillegg iterer over både produktet og prosessene, sørger man for en kontinuerlig forbedring av teamets effektivitet og verdiskapning, og igjen produktkvaliteten.
Hva som har blitt utført, hva som utføres, og hva som skal utføres i fremtiden, er informasjon som til enhver tid er synlig for alle. Dette virker informativt for produktets interessenter, samtidig som det vil ha en motiverende effekt for utviklerne. I løpet av et prosjekt er det dog normalt at kunden kan ombestemme seg, eller at det dukker opp uventede utfordringer. Den empiriske, inkrementelle og iterative tilnærmingen til Scrum aksepterer dette, og fokuserer heller på å maksimere evnen til å reagere og levere raskt.
Scrum er også skalerbart: Man kan ha flere parallelle utviklingsteam som jobber med samme produkt. Det bør likevel være kun èn dedikert produkteier som tar de endelige beslutningene om prioritet og funksjonalitet.
Scrum er enkelt å forstå, men svært vanskelig å mestre. Det vil kreve innsats og endringsvilje, og man må være åpen for å eksperimentere og utforske. Men når man først får tak i helheten og begynner å mestre Scrum, har man et utrolig kraftfullt sett av prinsipper og praksis som gjør at selv store og komplekse prosjekter blir gjennomførbare.