Å utvikle produkter, tjenester og prosesser som gir kundeverdi i dagens marked, er ikke alltid forenelig med langsiktig planlegging og tradisjonelle prosjektledelsesmetoder. Scrum er et enkelt agilt rammeverk som egner seg til komplekst arbeid i raskt skiftende omgivelser.
Raskere tilpasninger til markedet med Scrum
Scrum oppsto på 1990-tallet, og er basert på læring gjennom korte iterasjoner underveis mot målet. Hver iterasjon skal resultere i et eller flere inkrementer som det er mulig å sette i produksjon. Dette gjør det mulig å levere til kunder og brukere så hyppig som mulig, og dermed lære mer om brukerbehov og hvordan man kan justere og prioritere for å levere høyest mulig verdi. Scrum er i dag det mest vanlige agile rammeverket for teknologer.
«The Scrum Guide» beskriver rammeverket som bevisst mangelfullt, altså det er kun de overordnede prinsippene for Scrum som er definert. Det er opp til Scrum-teamet å detaljere den valgte arbeidsmetodikken, og mange ulike verktøy og metoder kan brukes innenfor Scrum. Det overordnede rammeverket er vist i figuren under.
Figur 1: Ved hjelp av Scrum kan vi jobbe i korte sprinter for å utvikle eller forbedre et produkt.
Scrum-teamet
Scrum-teamet består av inntil 10 personer som er bemyndiget av organisasjonen til å styre sitt eget arbeid. Det betyr at de selv bestemmer hvordan oppgaver skal utføres, og hvem som skal gjøre hva. Medlemmene i teamet skal ha alle ferdighetene som trengs for å skape verdi i hver sprint. Dermed er de ikke direkte avhengige av personer utenfor teamet. Teamet består av en Produkteier som er hovedansvarlig for hva som er rett produkt å utvikle, utviklere som har fokus på hvordan produktet bør utvikles, samt en Scrum Master som legger til rette for at teamet fungerer sammen, fjerner hindringer og er en pådriver for forbedring. Det er ingen formell prosjektlederrolle i Scrum, og titler som for eksempel Tech-lead eller testleder bør ikke benyttes i Scrum-teamet.
Figur 2: Scrum-teamet består av en Product Owner, Scrum Master og et utviklerteam som kommuniserer med interne og eksterne interessenter.
Et enkelt rammeverk for utvikling og problemløsning
Vi har tidligere nevnt at Scrum er et overordnet rammeverk, og at mange ulike verktøy og metoder kan brukes innenfor Scrum. Scrum kan dermed egne seg til mange ulike organisasjoner og prosjekter, spesielt i bransjer der det skjer raske endringer i omgivelsene, eller i prosjekter som krever kreativitet, fleksibilitet og innovasjon. Scrum er også et egnet rammeverk for operasjonell forbedring og forbedringsarbeid i komplekse organisasjoner. Denne tilnærmingen gjør det mulig å bryte forbedringsmål ned i håndterbare og målbare oppgaver og prioritere effektivt ut fra innsikt i brukerbehov. Det er stor mulighet for testing og hyppige tilbakemeldinger fra brukere, noe som reduserer risikoen for å løse feil problem eller bruke store ressurser på problemer som ikke bør være høyest prioritet. Teamstrukturen i Scrum, der teamet har myndighet til å selv finne beste løsning og metode, har også fellestrekk med andre velkjente rammeverk for forbedringsarbeid, f.eks. Lean.
Scrum i kreftbehandling i helsesektoren
For å vise hvordan Scrum kan benyttes i et forbedringsprosjekter ser vi nærmere på et eksempel fra et helseforetak som ønsker å forbedre pasientflyt og behandling for kreftpasienter. Dersom organisasjonen ønsker å benytte Scrum til å forbedre dette, opprettes det et Scrum-team som har ferdighetene som trengs for å løse problemet. Teamet kan bestå av sykepleiere, leger og andre medarbeidere på kreftavdelingen. Scrum-teamet må ha en Produkteier som for eksempel kan være en leder innen kreftbehandling, og en Scrum Master som har særlig kunnskap om Scrum. Det er viktig at teamet blir bemyndiget til å løse problemet innenfor visse rammer, og at de står fritt i hvilke arbeidsmetoder de velger å benytte.
Produktmål og Product Backlog
Produkteier har ansvaret for produktmålet og Product Backlog. I dette tilfellet kan et egnet produktmål for eksempel være: Å redusere gjennomsnittlig ventetid for kreftutredning og behandling med 50% innen 6 måneder.
Product Backlog er en overordnet liste over alle krav eller behov som skal oppfylles for å nå produktmålet. Product Backlog er dynamisk, slik at Produkteier kan ta inn nye elementer og endre prioriteringsrekkefølge. I starten kan for eksempel Produkt Backlog se slik ut:
Figur 3: Eksempel på fremstilling av en Product Backlog med et estimat som beskriver størrelse på elementene: Small (S), Medium (M), Large (L).
Sprintmål og Sprint Backlog
Teamet bestemmer seg for at hver sprint skal vare i 3 uker. Første sprint starter med en sprintplanlegging, der teamet velger ut prioritert arbeid fra Product Backlogen og legger en realistisk plan. Før sprintplanleggingen har Produkteier reflektert rundt hva som vil gi mest verdi å lansere i første sprint, og innhentet innsikt fra interessenter. På bakgrunn av dette har Produkteier løftet delmålet «forbedret kommunikasjon» høyere opp. Teamet diskuterer de høyest prioriterte elementene som støtter opp om produktmålet, og definerer et mål for første Sprint. I dette tilfellet kan et aktuelt sprintmål f.eks. være: Forbedre pasientflyt og kommunikasjon.
De utvalgte, grovestimerte Produkt Backlog elementene brytes ned i mindre deloppgaver, og legges inn i Sprint Backlog. Slik får teamet en detaljert oversikt over hvilke oppgaver som skal utføres for å nå sprintmålet.
Figur 4: Eksempel på en Sprint Backlog med oppgaver knyttet til pasientflyt og kommunikasjon.
Daily Scrum
Arbeidet frem mot sprintmålet koordineres i daglige scrummøter på maks 15 minutter. I disse møtene oppdaterer teamet hverandre på hva de har gjort siden sist, hva de skal gjøre frem til neste møte og hva de ser av problemer og hindringer. Scrum Master sitt hovedfokus er å fjerne hindringer fra teamet, og legge til rette for at teamet hyppig får mulighet til å justere arbeidsmetoder, samarbeid og omfang.
Inkrementer og Definition of Done
I hver sprint utvikles det inkrementer, altså konkrete byggesteiner som leder til produktmålet. Et inkrement skal kunne brukes, og ha høy kvalitet, noe som gjør det mulig å teste eller lansere inkrementet til ekte brukere etter en sprint. For sprinten vi nettopp har sett på kan vi se for oss at disse inkrementene blir laget:
Utvikle en standardisert pasientflytprosess
- En ny, standardisert pasientflytprosess er nå tilgjengelig og implementert.
- Informasjonsmøter er satt opp og gjennomføres regelmessig ved oppstart av behandlingsforløpet.
- Det er opprettet et pasientforum der man jevnlig kan få og fange opp pasienttilbakemeldinger.
Forbedret kommunikasjon
- En ny kommunikasjonsprotokoll er implementert, som sikrer rask og klar deling av testresultater.
- Regelmessige oppdateringer til pasienter er nå en del av standard praksis, noe som har forbedret pasientenes opplevelse og trygghet.
- Kommunikasjonsprotokollen blir kontinuerlig justert basert på evalueringer av pasienttilfredshet, noe som har resultert i mer fornøyde pasienter.
For at hele teamet skal ha en felles forståelse av når et inkrement er ferdig må det settes en «Definition of Done» som utarbeides av Scrum-teamet i fellesskap. For inkrementet forbedret kommunikasjon kan dette være en Definition of Done:
- En kommunikasjonsprotokoll for rask deling av testresultater er utviklet og dokumentert.
- Regelmessige oppdateringer til pasienter er implementert.
- Tilbakemeldinger fra pasienter er samlet inn og evaluert.
- Nødvendige justeringer er gjort basert på tilbakemeldinger.
- Protokollen er godkjent av ledelsen.
Sprint Review og Sprint Retrospective
I slutten av en sprint gjennomføres en Sprint Review der Scrum-teamet går gjennom hva som ble ferdig, og demonstrerer det som er utviklet i sprinten for de mest aktuelle interessentene. Interessentene kan i dette tilfellet være pasienter, pårørende og relevante ansatte internt i organisasjonen. Det er viktig at Produkteier noterer seg innspill og tilbakemeldinger fra interessentene. Produkteier bør også presentere en oppdatert Product Backlog, og notere seg innspill fra interessenter på hva de ville ønsket å prioritere i neste sprint.
Sprint Retrospective er et møte som gjennomføres i slutten av hver sprint, men fokus på å forbedre teamets og organisasjonens effektivitet. Scrum Master er sentral i å fasilitere dette, og hensikten er å lære av erfaring slik at prosessen kan forbedres.
Scrum – enkel å forstå, utfordrende å mestre
Scrum er et enkelt og effektivt rammeverk, men det krever innsats og forståelse å implementere det riktig. Som nevnt tidligere er fleksibiliteten i Scrum både en styrke, men også en utfordring. Uten konkrete verktøy eller detaljerte retningslinjer, kan rammeverket misforstås eller tilpasses på måter som svekker dets effektivitet. Eksempler på dette er bedrifter som hevder å bruke Scrum, men unnlater å holde daglige scrummøter eller ignorerer viktige møter som Sprint Retrospective.
For å sikre at Scrum virkelig fungerer etter hensikten, spiller Scrum Master en avgjørende rolle. De er ikke bare ansvarlige for å opprettholde rammeverket, men også for å veilede team og organisasjoner i hvorfor de ulike elementene i Scrum er viktige. Gjennom god implementering og kontinuerlig læring kan Scrum hjelpe bedrifter med å skape fleksible, produktive og tilpasningsdyktige team.
Riktig bruk av Scrum krever dedikasjon, men belønningen kan være stor for både team og organisasjoner som helhet!
Om Kjerstin Østerberg
