Scrum vs. Kanban: Hvilken skal I vælge?
Scrum arbejder i tidsafgrænsede sprints med forpligtelser og passer til produktudvikling hvor man planlægger i cyklusser. Kanban er et kontinuerligt flow med grænser for igangværende arbejde og passer til drift, vedligeholdelse og support hvor prioriteterne skifter. Mange teams ender i en hybrid. Som kunde bør du fokusere på rapporteringen, ikke på metodens navn.
Scrum og Kanban nævnes ofte i samme åndedrag, som to varianter af “agilt arbejde”. De hænger sammen, men de løser forskellige problemer. Vælger teamet metode efter mode i stedet for efter hvordan arbejdet faktisk ser ud, opstår der gnidninger. Her er forskellen i klart sprog, hvilken slags arbejde hver af dem passer til, og hvorfor de fleste teams i praksis ender et sted midt imellem.
Grundforskellen: sprints eller flow
Kernen i forskellen handler om hvordan arbejdet pakkes ind i tid.
Scrum deler arbejdet op i sprints, altså faste tidsperioder på ofte to uger. Før hver sprint forpligter teamet sig til en mængde arbejde, arbejder med det i perioden og leverer et resultat til sidst. Så begynder cyklussen forfra. Rytmen er forudsigelig og giver naturlige lejligheder til at planlægge, vise frem og omprioritere.
Kanban har ingen sprints. I stedet flyder opgaverne kontinuerligt gennem teamet: En ny opgave trækkes ind når der er kapacitet, uafhængigt af en kalender. Det centrale værktøj er en grænse for igangværende arbejde (WIP-grænse), som begrænser hvor meget der må være i gang samtidig. Fokus ligger på et jævnt og ubrudt flow frem for på cyklusser.
Kort sagt: Scrum planlægger i faste tidsrammer med forpligtelser, Kanban optimerer et løbende flow uden dem.
Hvilken type arbejde passer til hvilken metode?
Valget bør styres af arbejdets natur, ikke af hvad der lyder mest moderne.
| Situation | Passer bedst |
|---|---|
| Produktudvikling efter en plan | Scrum |
| Vedligeholdelse, drift og support | Kanban |
| Blanding af nyudvikling og løbende sager | Hybrid |
Scrum er stærkest når I bygger noget nyt efter en plan. Sprintrytmen giver et jævnt tempo, forudsigelige leverancer og tydelige lejligheder til at afstemme retningen. Det passer til produktudvikling hvor I nogenlunde ved hvor I skal hen og vil nå dertil i strukturerede skridt.
Kanban er stærkest når arbejdet er uforudsigeligt. Vedligeholdelse og support lever af indkommende sager der ikke kan vente på næste sprint, og en akut fejl skal tages med det samme. Det kontinuerlige flow og WIP-grænserne gør at teamet kan håndtere det der dukker op uden at sprænge en planlagt cyklus. At tvinge supportarbejde ind i sprints på to uger fører som regel bare til at sprinten hele tiden bliver brudt.
Et konkret eksempel
Forestil dig et team der først bygger en ny app og derefter vedligeholder den. I byggefasen passer Scrum: Teamet planlægger i sprints på to uger, leverer funktioner i tydelige skridt, og du får en forudsigelig rytme at følge. Alle ved hvad der skal være færdigt og hvornår.
Når appen først er lanceret, ændrer arbejdet karakter. Nu handler det om fejlrettelser, mindre forbedringer og supportsager der kommer ind løbende og uregelmæssigt. Her begynder sprintmodellen at knirke, for en akut fejl kan ikke vente to uger. Teamet glider så naturligt over mod Kanban med et flow af sager og en WIP-grænse der holder orden. Samme team, samme produkt, men forskellig metode i forskellige faser.
Hybriden er normen, og hvad du bør forvente
I praksis følger få teams nogen af metoderne slavisk. Den mest almindelige virkelighed er en hybrid, nogle gange kaldet Scrumban: Man beholder sprintrytmen, men tilføjer WIP-grænser og håndterer det der kommer ind mellem planlægningerne, på en mere flowbaseret måde. Det er ikke snyd, men sund fornuft. Man tager det der virker fra begge.
For dig som kunde er den vigtigste indsigt at metodens navn betyder mindre end du måske tror. Det du skal interessere dig for, er rapporteringen: Får du løbende og forståelig indsigt i hvad der er leveret og hvad der mangler? Kan du se retningen og omprioritere når det er nødvendigt? Både Scrum og Kanban kan give dig det. Forvent den indsigt uanset hvilket ord teamet sætter på sin arbejdsform.
Vi hos Weapp tilpasser arbejdsformen efter hvor produktet befinder sig, og holder rapporteringen tydelig uanset metode. Vil du vide hvordan vi ville tilrettelægge dit projekt? Læs om vores ydelser, eller kontakt os med en kort beskrivelse.
Ofte stillede spørgsmål
Hvad er den grundlæggende forskel på Scrum og Kanban?
Scrum deler arbejdet op i sprints, altså faste tidsperioder på ofte to uger med en forpligtelse til hvad der skal leveres. Kanban har ingen sprints, men et kontinuerligt flow hvor opgaverne trækkes ind hen ad vejen, med en grænse for hvor meget der må være i gang samtidig. Scrum planlægger i cyklusser, Kanban optimerer et løbende flow.
Hvilken metode passer til produktudvikling?
Scrum passer ofte bedre til produktudvikling, hvor man bygger nyt efter en plan og vil levere i tydelige cyklusser. Sprintrytmen giver forudsigelige statusmøder og en naturlig lejlighed til at omprioritere før hver ny periode. Det gør fremdriften let at følge og skaber et jævnt tempo at planlægge efter.
Hvornår er Kanban et bedre valg?
Kanban passer til vedligeholdelse, drift og support, hvor arbejdet kommer ind løbende og prioriteterne skifter hurtigt. En akut fejl kan ikke vente på næste sprint. Det kontinuerlige flow og grænserne for igangværende arbejde gør at teamet kan håndtere det uforudsigelige uden at sprænge en planlagt cyklus.
Hvad betyder WIP-grænser i Kanban?
WIP står for work in progress, altså igangværende arbejde. En WIP-grænse er et loft over hvor mange opgaver der må være i gang samtidig. Formålet er at undgå at alt bliver påbegyndt, men intet bliver færdigt. Når antallet af parallelle opgaver begrænses, bliver flowet jævnere, og tingene bliver faktisk afsluttet i stedet for at gå i stå halvvejs.
Kan man kombinere Scrum og Kanban?
Ja, og mange teams gør det. En almindelig hybrid, nogle gange kaldet Scrumban, beholder sprintrytmen, men tilføjer WIP-grænser og en mere flowbaseret måde at håndtere indkommende arbejde på. Pointen er at tage det der virker fra begge frem for at følge en metode dogmatisk. Den rigtige blanding afhænger af hvordan arbejdet faktisk ser ud.
Betyder metodevalget noget for mig som kunde?
Mindre end man tror. Det der betyder noget for dig, er at du får løbende og forståelig indsigt i hvad der bliver leveret og hvad der mangler. Både Scrum og Kanban kan give det. Fokuser derfor på rapporteringen og rytmen i statusmøderne frem for på hvilket metodenavn teamet sætter på sin arbejdsform.