Scrum og Agile

Scrum er et rammeverk som hjelper team med å skape og levere verdi. Gjennom faste hendelser og møter inspirerer det arbeidet både før, etter og underveis. Det skjer innenfor definerte tidsperioder kjent som sprints, og varer typisk ca. én måned.

“Scrum er en gratis tilnærming som presenteres gjennom denne veiledningen. Scrum sine roller, møter, artefakter og regler er konstante og uforanderlige. Selv om det kun er mulig å implementere deler av Scrum, vil resultatet ikke være en fullstendig Scrum-prosess. Scrum eksisterer kun som en helhet og fungerer som en ramme for andre teknikker, metoder og praksiser” Kilde: Utdrag fra Scrum Guiden 2020 (Norsk)Agile er et sett med prinsipper som man følger når man arbeider, som beskrevet  i Agile Manifesto. Når man jobber agilt, kalles den definerte tidsperioden en Iterasjon, som i hovedsak tilsvarer en Sprint i Scrum.

Uansett hvilken tilnærming du velger å jobbe med – Agile, SCRUM, SAFe, XP eller Kanban – handler det om å skape verdi. Jo hyppigere man får produktet eller tjenesten ut til sluttbrukerne, jo bedre innsikt får man i om det man gjør gir den ønskede verdien.

Det er vanlig å ha en tidsavgrenset periode når man skal levere, som kan kalles en sprint. Videre vil jeg utforske ulike metaforer for å forklare hvordan prosessene fungerer, i håp om å gi deg bedre innsikt og forståelse av hva det innebærer.

Metaforer

I dette innlegget vil jeg utforske metaforer som kan forklare produktutvikling innenfor rammene av Agile og Scrum. Dette er mine personlige refleksjoner basert på min kunnskap og forståelse av emnet. Jeg vil forklare metaforene “spise kake”, “lage kake”, “muffins”, “lønn” og “kjøretur” og hvordan alle disse kan sammenlignes med hvordan man jobbe med Agile og Scrum.

“Alle modeller er feil, men noen er hjelpsomme” er et utsagn jeg hørte under Agile Team Coach ICP-ACC. Dette understreker viktigheten av å ikke betrakte modeller som sannheter, men heller som et verktøy for å oppnå mål. Når det kommer til metaforer, er det vanlig at enkeltpersoner skaper sine egne for at de skal gi mening, selv om de kanskje ikke matcher virkeligheten. Det er viktig å være varsom med å avvise en metafor for å si at den er “feil”, siden den er basert på individuelle perspektiver. Selv om visse metaforer kan bli akseptert som mer nøyaktige av fellesskapet etter hvert, er det essensielt å huske på at ingen modeller er perfekte, men kan være nyttige likevel.

Det minner meg om min tilnærming til læring og hvordan jeg tilegner meg informasjon på nett. Det første svaret eller den mest åpenbare løsningen er ikke alltid den som gir mest og best innsikt. Ofte må jeg søke etter en forklaring som passer meg og mitt nivå av forståelse. Noen ganger er det de mer komplekse forklaringene som gir dypere innsikt, mens andre ganger er de enkle svarene tilstrekkelig.

Spise Kake (Epics, User Stories og Features)

Scrum refererer til Product Backlog og elementer i Product Backlog, men gir ingen spesifikk veiledning om hva de skal inneholde eller hvordan de skal organiseres og struktureres. Det som fokuseres på er “Definition of Done” for hvert element i Product Backlog, slik at man kan verifisere at alle nødvendige trinn er utført for å si at det er ferdig og klart til bruk.

Det finnes flere måter å organisere arbeidet på, og det er opp til Product Owner (PO) og teamet å bestemme hva som passer best. Mange bruker EPICS, Features, User Stories og Tasks for å strukturere og organisere backloggen. Men det trenger ikke å være så komplisert; mange velger å kun ha User Stories og Tasks, eller Features. Det viktigste er å bryte ned oppgavene i mindre deler slik at de kan utføres innenfor en sprint.

En kake-metafor kan gi innsikt i hvordan man kan tenke rundt Product Backlog-elementer i sammenheng med EPIC, Feature, User Stories og Tasks. Forestill deg at en EPIC er en hel kake. Det er umulig å spise en hel kake i ett jafs. Denne spesielle kaken består av fire forskjellige typer kake: ¼ sjokolade, ¼ gulrotkake, ¼ bløtkake og ¼ verdens beste.

Hver av disse representerer en Feature. Men en Feature er fortsatt for stor til å spise i et jafs, så den må også deles inn i mindre User Stories. User Stories blir da kakestykker, og nærmer seg en størrelse som er passelig å spise. En mulighet er å dele ut flere kakestykker til andre slik at man sammen kan klare å spise opp en ¼ av kaken.

Men det er fortsatt ikke så lett å stappe et helt kakestykke i munnen. Derfor må vi dele det opp i tasks (mindre biter), slik at du kan spise litt og litt av stykket og til slutt bli ferdig med ett stykke før du tar det neste. På denne måten, når tiden går ut, har du klart å spise opp x deler av kaken.

En alternativ tilnærming kan være å plassere kaken foran teamet, gi dem hver sin spiseskje og be dem spise opp. Faren her er at kaken raskt kan se ut som en sveitsisk ost, hvor den ikke kan spares eller deles videre, fordi få ønsker å spise en kake som allerede ser spist ut. Derfor deler vi ofte kaken i kakestykker, gir hver person sin egen tallerken, og hvis det blir rester igjen, er det mulig å spise kaken senere uten at den ser ut som en sveitsisk ost.

Lage Kake (utradisjonelt)

Mange er kjent med hvordan en kake lages. Det gjøres vanligvis i steg hvor man lager bunnen først, deretter fyllet, etterfulgt av toppingen. Men innenfor Scrum og Agile er ikke dette helt optimalt. Grunnen er at man ikke får mulighet til å vite hvordan kaken smaker før den er helt ferdig. Selvfølgelig kan man smake underveis, men det er først når kaken er helt ferdig at man faktisk kan finne ut om den smaker som forventet og om kombinasjonen fungerer.

Så i denne metaforen gjør vi en liten vri på kakebaking for å få det til å passe inn i det agile tankesettet. Produktutviklingen kan sammenlignes med å bake en kake.

Produkteieren har bestemt at teamet skal lage en marsipankake med følgende ingredienser:

• vanlig sukkerbrød,
• bringebærkrem,
• hvit marsipanlokk og frukt på toppen (physalis og rips).

Teamet lager et kakestykke ut ifra dette, og under Sprint Review får produkteieren se og smake på stykket. produkteieren oppdager at bringebærkremen ikke var som forventet og foretrekker sjokoladekrem i steden. Dette legges til som en ny oppgave for neste sprint.

Ved neste sprint planlegger teamet og spør produkteieren hva som menes med sjokoladekrem. Er det 70 % sjokolade, 50 % melkesjokolade, kokesjokolade eller belgisk sjokolade? produkteieren synes vanlig melkesjokolade er et godt valg.

Teamet starter å lage kakestykket, og under neste Sprint Review får produkteieren smake på stykket og er fornøyd med sjokoladekremen. Det som imidlertid har endret seg, er at frukt på toppen ikke lenger er ønskelig; nå foretrekkes makroner.

Slik fortsetter det til man har fått et stykke man er fornøyd med, som smaker og ser ut slik man ønsker. Naturligvis vil en ferdig kake av dette se litt ut som et Frankenstein-monster, eller kanskje en veldig pen regnbuekake, med forskjellige elementer på toppen.

Forsøket på å forklare metaforisk hva en sprint og en oppgave er, kan være til hjelp. Kanskje det er bedre å snakke om å lage mindre kaker, eller kanskje muffins passer bedre? Jeg prøver meg på en muffins-metafor nedenfor og ser om det gir mer mening.

Muffins (Lage kake på en annen måte)

Muffins kan kanskje være enklere å forstå når det gjelder hvordan sprinter kan foregå. Forestill deg at du skal lage 1000 muffins til et skolearrangement. Du skal selv bestemme hvilke smaker du vil ha; vil du ha bare én smak eller flere? Du har aldri laget muffins før, så hva gjør du?

Du søker opp en oppskrift på standard muffins og lager deig til 6 muffins. En helt standard deig gir deg muligheten til å eksperimentere med smak og topping. I én muffins legger du blåbær, i en annen sjokoladebiter. Du prøver en med peanøttsmør og jordbærsyltetøy, osv. Deretter setter du dem i ovnen og baker.

Etter at muffinsene er ferdig bakt, smaker du på dem og finner ut at blåbærmuffinsene er gode, men de mangler noe. Muffins med peanøttsmør, derimot, føles for kraftig. Du oppdager at det er vanlig å tilsette vanilje i deigen for muffins med sjokoladebiter eller blåbær for å forbedre smaken. Samtidig ønsker du å prøve en friskere muffin og finner en oppskrift på sitronvalmuemuffins.

Du bestemmer deg for å lage en ny runde med seks muffins: to med blåbær, to med sjokoladebiter (begge med vanilje i deigen), og de to siste som sitronvalmuemuffins. De ferdige muffinsene deler du opp i flere biter og gir til en gruppe med barn som du har spurt om hjelp.

Barna rangerer muffinsene, og resultatet viser at sjokolademuffinsene er klart best, mens den friske sitronvalmuemuffinsen er en god nummer to. Etter nøye vurdering bestemmer du deg for å lage halvparten med sjokolade og resten med sitronvalmuemuffins.

Oppsummert kan en sprint sammenlignes med hvordan man baker muffins. Selvfølgelig er det ikke  svart-hvitt, men det kan hjelpe å tenke litt i disse muffins-banene.

Lønn (hvor ofte vil du ha lønn)

Har du noen gang lurt på hvorfor vi får lønn månedlig, eller annenhver uke? Hvorfor vil du ikke ha lønn årlig? Hvis arbeidsgiveren din foreslo at du skulle få lønnen din ved slutten av året, ville du ha sagt ja? Du ville jo fått samme lønn uansett, men da ville du selv vært ansvarlig for å fordele den utover året.

Men hva skjer hvis arbeidsgiveren din går konkurs i løpet av året? Dette er nok en av grunnene til at vi foretrekker regelmessige utbetalinger. Jo oftere du får utbetalt, jo mindre taper du hvis arbeidsgiveren skulle gå konkurs.

Denne tankegangen er den samme som ligger bak levering i iterasjoner eller Sprints i Smidig. Man leverer heller ofte og i mindre mengder, i stedet for å bruke 6-12 måneder på å levere. På denne måten vet man om arbeidet man gjør er mer i tråd med det brukerne eller kunden ønsker. Skulle prosjektet plutselig stoppe opp, så har man noe å vise til, i stedet for et halvferdig produkt som ikke fungerer.

Kjøretur (SPRINT)

Kjøretur er en metafor jeg bruker for å forklare hvordan sprints fungerer i Scrum. Denne metaforen ble inspirert av en episode av Agile Mentors Podcast, hvor de diskuterte hvordan prosjekteieren (PO) er den som fyller på drivstoff for teamet.

Før vi starter metaforen, la meg bare forklare noen nøkkelroller i Scrum: Scrum Master er lederen som veileder teamet; prosjekteier (PO), ansvarlig for produktets kvalitet for oppgavene; og utviklere (Developers), også kalt prosjektteamet, er de som trengs for å utvikle og forbedre produktet.

Forestill deg at du og teamet ditt skal på en kjøretur fra Oslo til Trondheim. Du har jevnlige stopp for å ta pauser og analysere hvordan det går – dette er våre sprints. Ved starten av hver sprint har PO prioritert å fylle opp lageret med bensinkanner i forskjellige størrelser.

Sprint planning er som å bestemme hvor mye drivstoff du tror du trenger for å nå neste stopp. Sammen med PO, må teamet velge antall bensinkanner og avgjøre om de er i riktige størrelser. Er de for store, tar det for lang tid å tømme dem; er de for små, blir det mange korte stopp for å fylle.

Målet er å gjette hvor mye drivstoff og bensinkanner som trengs, basert på begrenset informasjon om veien videre. Et sprintmål kan være som vår planlagte stopp på Lillehammer, med estimert tid og drivstoff. Balansen mellom antall og størrelse av bensinkanner er kritisk, hjulpet av Backlog Refinement. Sprint-planleggingen blir en strukturert utvelgelsesprosess.

Når teamet og PO er enige, starter kjøreturen, og her oppstår potensielle utfordringer. Teamet bestemmer hvordan de vil håndtere oppgavene underveis. Start med mange små, ta de store på slutten, eller motsatt? Det er opp til teamet å velge, kanskje kombinere små kanner for å få en medium kanne, slik at de kan komme seg lengre.

Uansett valg er kjøreforholdene den største usikkerheten. Oppoverbakker bruker mer drivstoff, nedoverbakker mindre. Veiarbeid skaper kø, bruker tid, men går ikke utover drivstoff. Etter 2.30 timer – har teamet nådd Lillehammer? Sprint Review gir svarene. Hvor mange kanner ble brukt, nådde de målet, og er PO fornøyd?

Sprint Retrospektiv analyserer hva som skjedde. Hva gikk som planlagt, hva kunne vært annerledes? Hva kan man forbedre til neste tur? Kanskje installere en radio for trafikkinformasjon?

Neste sprint starter, PO fyller opp flere bensinkanner, og målet kommuniseres. Teamet sjekker værmeldingen for Rondane Nasjonalpark, planlegger bedre og installerer vinterdekk. Sprinten gjentas, utfallene analyseres og forbedres kontinuerlig.

Til slutt

Som du kanskje forstår så er det kanskje ikke alltid så lett å prøve å forklare noe med metaforer, det finnes mange forskjellige måter å beskrive ting på, samtidig som at Agile og Scrum er et kompleks landskap å navigere i. Det sies jo at mange kokker blir mye søl. Og sånn er det nok her og . Derfor er det viktig å ikke se på metaforer som fasiten, men heller som et hjelpemiddel for å forstå deler av elementene. Velg de som du tenker fungerer best for deg.

‍