Scrum eller Kanban?

Av Weapp · Oppdatert

Scrum bruker tidsavgrensede sprinter med forpliktelser og passer for produktutvikling der man planlegger i sykluser. Kanban er en kontinuerlig flyt med grenser for pågående arbeid og passer for forvaltning og support der prioriteringene skifter. Mange team havner i en hybrid. Som kunde bør du fokusere på rapporteringen, ikke på metodenavnet.

Scrum og Kanban nevnes ofte i samme åndedrag, som to varianter av «smidig arbeid». De henger sammen, men de løser ulike problemer. Velger teamet metode etter hva som er på moten i stedet for etter hvordan arbeidet faktisk ser ut, blir resultatet friksjon. Her er forskjellen i klartekst, hvilket arbeid hver av dem passer for, og hvorfor de fleste team i praksis havner et sted midt imellom.

Grunnforskjellen: sprinter eller flyt

Kjernen i forskjellen er hvordan arbeidet fordeles i tid.

Scrum deler arbeidet inn i sprinter, faste tidsperioder på ofte to uker. Før hver sprint forplikter teamet seg til en mengde arbeid, jobber med det gjennom perioden og leverer et resultat på slutten. Så begynner syklusen på nytt. Rytmen er forutsigbar og gir naturlige anledninger til å planlegge, vise frem og prioritere på nytt.

Kanban har ingen sprinter. I stedet flyter oppgavene gjennom teamet kontinuerlig: En ny oppgave trekkes inn når det er kapasitet, uavhengig av noen kalender. Det sentrale verktøyet er en grense for pågående arbeid (WIP-grense), som begrenser hvor mye som får være i gang samtidig. Fokuset ligger på en jevn, ubrutt flyt snarere enn på sykluser.

Kort sagt: Scrum planlegger i tidsavgrensede sykluser med forpliktelser, Kanban optimaliserer en løpende flyt uten dem.

Hvilken metode passer for hvilket arbeid?

Valget bør styres av hva slags arbeid det er, ikke av hva som høres mest moderne ut.

SituasjonPasser best
Produktutvikling etter en planScrum
Forvaltning, drift og supportKanban
Blanding av nyutvikling og løpende sakerHybrid

Scrum er sterkest når dere bygger noe nytt etter en plan. Sprintrytmen gir et jevnt tempo, forutsigbare leveranser og tydelige anledninger til å sjekke at retningen stemmer. Det passer for produktutvikling der dere vet omtrent hvor dere skal, og vil komme dit i strukturerte steg.

Kanban er sterkest når arbeidet er uforutsigbart. Forvaltning og support handler om innkommende saker som ikke kan vente til neste sprint: En akutt feil må tas med en gang. Den kontinuerlige flyten og WIP-grensene gjør at teamet kan ta unna uforutsette saker uten at en planlagt syklus sprekker. Å tvinge supportarbeid inn i sprinter på to uker fører som regel bare til at sprinten stadig blir avbrutt.

Et konkret eksempel

Tenk deg et team som først bygger en ny app og deretter forvalter den. I utviklingsfasen passer Scrum: Teamet planlegger i sprinter på to uker, leverer funksjoner i tydelige steg, og du får en forutsigbar rytme å følge. Alle vet hva som skal være ferdig og når.

Når appen først er lansert, endrer arbeidet karakter. Nå handler det om feilrettinger, mindre forbedringer og supportsaker som kommer inn løpende og uregelmessig. Her begynner sprintmodellen å komme til kort: En akutt feil kan ikke vente i to uker. Teamet glir da naturlig over mot Kanban, med en flyt av saker og en WIP-grense som holder orden. Samme team, samme produkt, men ulik metode i ulike faser.

Hybriden er normen, og dette bør du forvente

I praksis følger få team en av metodene helt etter boken. Den vanligste virkeligheten er en hybrid, noen ganger kalt Scrumban: Man beholder sprintrytmen, men legger til WIP-grenser og en mer flytbasert håndtering av det som kommer inn mellom planleggingene. Det er ikke juks, men sunn fornuft: Man tar med seg det som fungerer fra begge.

For deg som kunde er den viktigste innsikten at metodenavnet betyr mindre enn du kanskje tror. Det du bør bry deg om, er rapporteringen: Får du jevnlig og forståelig innsyn i hva som er levert, og hva som gjenstår? Kan du se retningen og prioritere på nytt når det trengs? Både Scrum og Kanban kan gi deg det. Forvent det innsynet uansett hvilket ord teamet setter på arbeidsmåten sin.

Vi i Weapp tilpasser arbeidsmåten etter hvor produktet befinner seg, og holder rapporteringen tydelig uansett metode. Vil du vite hvordan vi ville lagt opp prosjektet ditt? Les om tjenestene våre eller ta kontakt med en kort beskrivelse.

Ofte stilte spørsmål

Hva er den grunnleggende forskjellen på Scrum og Kanban?

Scrum deler arbeidet inn i sprinter, faste tidsperioder på ofte to uker, med en forpliktelse om hva som skal leveres. Kanban har ingen sprinter, men en kontinuerlig flyt der oppgaver trekkes inn etter hvert, med en grense for hvor mye som får pågå samtidig. Scrum planlegger i sykluser; Kanban optimaliserer en løpende flyt.

Hvilken metode passer for produktutvikling?

Scrum passer ofte bedre for produktutvikling, der man bygger nytt etter en plan og vil levere i tydelige sykluser. Sprintrytmen gir forutsigbare oppfølgingsmøter og en naturlig anledning til å prioritere på nytt før hver nye periode. Det gjør fremdriften lett å følge og skaper et jevnt tempo å planlegge etter.

Når er Kanban et bedre valg?

Kanban passer for forvaltning, drift og support, der arbeidet kommer inn løpende og prioriteringene skifter raskt. En akutt feil kan ikke vente til neste sprint. Den kontinuerlige flyten og grensene for pågående arbeid gjør at teamet kan håndtere det uforutsigbare uten at en planlagt syklus sprekker.

Hva betyr WIP-grenser i Kanban?

WIP står for work in progress, altså pågående arbeid. En WIP-grense er et tak for hvor mange oppgaver som får være i gang samtidig. Formålet er å unngå at alt blir påbegynt, men ingenting blir ferdig. Ved å begrense antallet parallelle oppgaver blir flyten jevnere, og ting blir faktisk fullført i stedet for å bli stående halvveis.

Kan man kombinere Scrum og Kanban?

Ja, og mange team gjør det. En vanlig hybrid, noen ganger kalt Scrumban, beholder sprintrytmen, men legger til WIP-grenser og en mer flytbasert håndtering av innkommende arbeid. Poenget er å ta med seg det som fungerer i begge, i stedet for å følge én metode dogmatisk. Riktig blanding avhenger av hvordan arbeidet faktisk ser ut.

Spiller metodevalget noen rolle for meg som kunde?

Mindre enn man tror. Det som betyr noe for deg, er at du får jevnlig og forståelig innsyn i hva som leveres, og hva som gjenstår. Både Scrum og Kanban kan gi det. Fokuser derfor på rapporteringen og rytmen i oppfølgingsmøtene snarere enn på hvilket metodenavn teamet setter på arbeidsmåten sin.