Scrum eller Kanban?

Scrum och Kanban nämns ofta i samma andetag, som två varianter av “agilt arbete”. De hänger ihop, men de löser olika problem. Väljer teamet metod efter mode i stället för efter hur arbetet faktiskt ser ut, blir resultatet friktion. Här är skillnaden i klartext, vilken sorts arbete som passar respektive, och varför de flesta team i praktiken hamnar någonstans mittemellan.

Grundskillnaden: sprintar eller flöde

Kärnan i skillnaden handlar om hur arbetet paketeras i tid.

Scrum delar in arbetet i sprintar – fasta tidsperioder, ofta två veckor. Inför varje sprint åtar sig teamet en mängd arbete, jobbar med det under perioden och levererar ett resultat i slutet. Sedan börjar cykeln om. Rytmen är förutsägbar och ger naturliga tillfällen att planera, visa upp och prioritera om.

Kanban har inga sprintar. I stället flödar uppgifter genom teamet kontinuerligt: en ny uppgift dras in när det finns kapacitet, oberoende av någon kalender. Det centrala verktyget är en gräns för pågående arbete (WIP-gräns), som håller nere hur mycket som får vara igång samtidigt. Fokus ligger på ett jämnt, obrutet flöde snarare än på cykler.

Kort sagt: Scrum planerar i tidsboxar med åtaganden, Kanban optimerar ett löpande flöde utan dem.

Vilken arbetstyp passar vilken metod?

Valet bör styras av arbetets natur, inte av vad som låter modernast.

Scrum lyser när ni bygger något nytt mot en plan. Sprintrytmen ger en jämn takt, förutsägbara leveranser och tydliga tillfällen att stämma av riktning. Det passar produktutveckling där ni vet ungefär vart ni ska och vill ta er dit i strukturerade steg.

Kanban lyser när arbetet är oförutsägbart. Förvaltning och support lever på inkommande ärenden som inte kan vänta på nästa sprint – ett akut fel måste tas direkt. Det kontinuerliga flödet och WIP-gränserna gör att teamet kan hantera det som dyker upp utan att spränga en planerad cykel. Att tvinga in supportarbete i tvåveckorssprintar leder oftast bara till att sprinten ständigt bryts.

Ett konkret exempel

Tänk dig ett team som först bygger en ny app och sedan förvaltar den. Under byggfasen passar Scrum: teamet planerar i tvåveckorssprintar, levererar funktioner i tydliga steg och du får en förutsägbar rytm att följa. Alla vet vad som ska vara klart och när.

När appen väl är lanserad förändras arbetets karaktär. Nu handlar det om buggrättningar, mindre förbättringar och supportärenden som kommer in löpande och oregelbundet. Här börjar sprintmodellen skava – ett akut fel kan inte vänta två veckor. Teamet glider då naturligt över mot Kanban, med ett flöde av ärenden och en WIP-gräns som håller ordning. Samma team, samma produkt, men olika metod i olika faser.

Hybriden är normen – och vad du bör förvänta dig

I praktiken följer få team någon av metoderna renlärigt. Den vanligaste verkligheten är en hybrid, ibland kallad Scrumban: man behåller sprintrytmen men lägger till WIP-gränser och ett mer flödesbaserat sätt att hantera det som kommer in mellan planeringarna. Det är inte fusk, utan sunt förnuft – man tar det som fungerar från båda.

För dig som beställare är den viktigaste insikten att metodnamnet spelar mindre roll än du kanske tror. Det du ska bry dig om är rapporteringen: får du regelbunden, begriplig insyn i vad som levererats och vad som återstår? Kan du se riktningen och prioritera om när det behövs? Både Scrum och Kanban kan ge dig det – förvänta dig den insynen oavsett vilket ord teamet sätter på sitt arbetssätt.

Vi på Weapp anpassar arbetssättet efter var produkten befinner sig, och håller rapporteringen tydlig oavsett metod. Vill du veta hur vi skulle lägga upp ditt projekt? Läs om våra tjänster eller hör av dig med en kort beskrivning.