Kanban eller Scrum?

Kompetanseutvikling

3 min. lesning

I PRINCE2 beskrives prosessen «styre produktleveranser» som samhandlingen mellom prosjektleder og teamleder(e). Prosessen tar for seg prosjektet fra en teamleders perspektiv og skal sørge for at prosjektteamet har forståelse for hva som skal leveres innenfor de rammene som er definert for tid og kostnad. I smidige prosjekter ønsker man at selvorganiserte team skal gjennomføre leveransene.

De to mest populære smidige rammeverkene for selvorganiserte team er Scrum og Kanban. Begge metodene fokuserer på teamarbeid og kontinuerlig forbedring av teamet, men hvordan de strukturerer arbeidet er svært ulikt.

I dette blogginnlegget går vi igjennom forskjellen på Scrum og Kanban og i hvilke situasjoner de bør brukes.

Scrum

I Scrum fordeler man prosjektet opp i faste tidsperioder som kalles «sprinter» eller «iterasjoner». Disse har vanligvis en varighet på to til fire uker, og teamet gjennomfører en bestemt mengde arbeid innenfor hver sprint. For at sprintene skal gjennomføres best mulig gjennomfører teamet regelmessige møter. Disse møtene inkluderer planlegging av sprintene, prioritering av arbeid, statusrapportering, samt vurdering av hver sprint.

I et Scrum-prosjekt må man ha følgende ressurser dedikert til prosjektteamet:

  • Utviklere: Disse jobber tett sammen for å utvikle produktet og oppnå målene i hver sprint.
  • Scrum Master: Denne rollen fungerer som en coach som hjelper prosjektteamet med bruk av Scrum-metodikk, samt å utvikle seg over tid.
  • Produkteier: Denne rollen definerer prosjektmålene og tar viktige beslutninger, samt sikrer forståelse av brukersiden av prosjektet.

LES OGSÅ: Scrum - et enkelt rammeverk for komplekst arbeid

Kanban

I motsetning til Scrum, er Kanban en mer fleksibel tilnærming til et smidig rammeverk. Kanban fokuserer på å optimalisere arbeidsflyt og kontinuerlig forbedre prosesser, uten faste tidsrammer. Arbeidselementer leveres så snart de er ferdige, noe som gir en jevn strøm av leveranser.

I et Kanban-prosjekt setter teamet begrensninger på hvor mange aktiviteter som kan være i gang samtidig (Work In Progress limits) for å unngå overbelastning. I tillegg bruker teamet visuelle tavler (Kanban boards) til å spore og administrere arbeidet gjennom ulike stadier (f.eks To Do, In Progress, Done). Dette gir teamet mulighet til å prioritere arbeid og jevnlig evaluere prosessene sine, slik at flaskehalser og forbedringsområder identifiseres. Dermed kan arbeidsprosessene justeres for å bli mer effektiv.

LES OGSÅ: Hva er Kanban

Scrum eller Kanban?

Oppsummert passer Scrum best for prosjekter med klare mål og hvor det er behov for regelmessige leveranser innenfor faste tidsrammer. Dette er prosjekter som ofte krever samarbeid mellom forskjellige fagområder, og har behov for struktur og forutsigbarhet.

Kanban passer mer for prosjekter som krever kontinuerlig leveranse og hvor prioriteringer kan endre seg raskt. Dette kan eksempelvis være support- og vedlikeholdsprosjekter. Kanban kan derfor passe best for prosjekter som har behov for fleksibilitet eller for team som ønsker å forbedre eksisterende arbeidsprosesser.

Bli sertifisert ScumMaster med vårt to-dagers kurs


Lene jobber med virksomhetsutvikling innen prosjektbaserte industrivirksomheter. Hun har bakgrunn som sivilingeniør innen industriell økonomi og har prosjektledererfaring fra store offentlige byggeprosjekter. Lene er spesielt interessert i å hjelpe virksomheter med å utvikle seg gjennom å implementere smartere prosesser. Fritiden tilbringes helst på fjellet eller på reisefot til en spennende destinasjon.


Likte du dette blogginnlegget? Da tror vi at disse også passer for deg

8 nye oppdateringer i PRINCE2 Agile®

Siste utgave av PRINCE2 Agile® (v. 2) kombinerer PRINCE2s styringsstruktur med smidige prinsipper og metoder. Som et rammeverk gir det både kontroll der det trengs, og rom for reell smidig utvikling der det er rom for det.

Slik kan AI støtte deg med dataanalyse og innsikt

Mange virksomheter sitter på store mengder data de verken har full oversikt over eller utnytter godt nok. Dermed går de glipp av muligheter til å forbedre produkttilbudet, øke effektiviteten eller optimalisere prosjektporteføljen.

Det er alltid behov for mer kompetanse i en IT-omstilling

Det er alltid behov for mer kompetanse i en IT-omstilling – og det er umulig å vite hva som trengs på forhånd. I de omstillingene med IT som jeg har vært med på, har det vært en kontinuerlig mangel på kompetanse. Det gjelder mange sider av omstillingen, enten det er teknologi, støtteverktøy, gevinster, arbeidsprosesser og -metoder, kultur, tjenesteinnhold, organisering eller ledelse. Da jeg oppdaget kompetansemangelen opplevdes det som om det var noe feil eller mislykket med omstillingen. Kom det fra forberedelsene, planleggingen eller gjennomføringen? Var kilden til problemet manglende kompetansebudsjetter, kompetanse hos lederne eller var det noe helt annet som spilte inn? Jeg kom frem til at svaret var ganske sammensatt. Her deler jeg noen vurderinger og forslag til hvordan utfordringen kan håndteres.