Vi har lavet en sammenligning mellem Scrum og Kanban på fem punkter. Det er ikke fyldestgørende, men giver dig et overblik over de største og mest afgørende forskelle på de to arbejdsgange.
Det er vigtigt at slå fast, at dette IKKE er en komplet oversigt over hverken Scrum eller Kanban!
Der er mange forskellige måder at implementere både Scrum og Kanban på i en konkret hverdag. Det du får i dette indlæg er et overblik – ikke en komplet guide.
Hvis du gerne vil have den korte TLDR-version (Too Long; Didn’t Read), så kommer den her:
TL;DR-versionen
Kanban
- Sikrer transparens i organisationen, fordi alle kan se status på opgaverne
- Opgaverne bliver prioriteret
- Work-In-Progress Limits sikrer, at prioriteringen overholdes og fokus fastholdes
Scrum
- Bedre til at håndtere langsigtet planlægning
- Kan håndtere et større setup med flere teams
- Opdeling af opgaver i sprints sikrer en fastlagt og struktureret evaluering og optimering af arbejdsgangene
Den længere version
Vi har beskrevet forskellen mellem Scrum og Kanban på fem punkter. Inden vi løber dem igennem, skal vi lige nævne den helt grundlæggende forskel: Scrum er et agilt og iterativt framework. Kanban er agilt, men ikke iterativt.
Begge frameworks er et forsøg på at strukturere en hverdag, hvor man er nødt til at tilpasse sig løbende for at levere den bedste løsning. Men hvor Scrum har et fast scope i form af et sprint, har man i Kanban ikke en fast tidsramme. Derfor er Scrum iterativt: Hver gang man er færdig med et sprint, starter et nyt og man gentager de samme events. Et sprint er på den måde en ny iteration, hvor man hver gang forsøger at gøre det lidt bedre og lidt smartere.
Det betyder ikke, at man i Kanban aldrig optimerer eller forsøger at blive bedre. Men måden man faciliterer den proces er anderledes end i Scrum.
Feedback loop vs Retrospectives
Det bringer os til det første af de fem punkter: Hvordan sørger man for, at arbejdsgangene løbende bliver optimeret?
I Kanban har man som sagt ikke sprints, så der er ikke et naturligt tidspunkt at holde Retrospectives på. I stedet har man feedback loops, som for eksempel et dagligt møde (Daily Meeting eller Daily Standup). Det sikrer en hurtig og løbende optimering og løsning af problemer. De langsigtede og mere overordnede udfordringer kan være sværere at fange i det daglige. Der har Scrum en fordel med Retrospectives.
Forudsigelighed vs tilfældighed
Årsagen til, at det ikke er så stort et problem er, at Kanbans styrke ligger i at håndtere en daglig produktion, der er præget af en stor grad af tilfældighed. Man møder ind om morgenen og har ikke den store idé om, hvad dagen kommer til at bringe. Der kan ligge opgaver fra dagen før, men der kan også sagtens komme nye opgaver ind, der har en højere prioritet. Opgaverne er ikke samlet i en klump og hænger ikke nødvendigvis sammen. De kan fint stikke i alle mulige retninger. Derfor er hurtige feedback loops vigtigere end langsigtet evaluering og optimering.
I Scrum derimod er hele formålet at skabe forudsigelighed og dermed minimere risici ved at fastlægge indholdet af et sprint og følge den planlægning så meget som det er muligt.
Push vs Pull
Det leder os hen til næste punkt, som beskriver forskellen på, hvordan opgaver organiseres: I Scrum skubber man opgaverne ind i et sprint (Push). I sprintet trækker teamets medlemmer så opgaverne, hvilket kan defineres som “Pull”. Men den overordnede organisering er dog “Push”.
Kanban trækker man opgaverne fra todo-bunken (Pull). Der er er ikke nogen gruppering eller organisering af opgaverne.
Estimering vs Work-In-Progress Limits
I begge tilfælde har man dog brug for en måde at sikre, at medarbejderne hjælpes til at holde fokus. I Scrum er udfordringen at sikre, at der ikke kommer for mange opgaver i et sprint, så teamet ikke leverer det forventede. Det håndteres ved at estimere opgaverne og sammenholde det med teamets kapacitet.
I Kanban sikrer man fokus på en anden måde, nemlig ved at begrænse, hvor mange opgaver, der må være igang på samme tid (Work-In-Progress Limits, forkortet WIP Limits). Er WIP-limit nået, er der to muligheder, hvis en ny opgave skal sættes igang: Enten skal der løses en opgave eller også skal en opgave rykkes tilbage til “Todo”. Det kan ske, når opgaven ikke er specificeret ordentligt eller der er et uventet problem, som skal vendes på morgendagens møde.
Projekt vs proces
Det sidste punkt er vores bud på, hvornår Scrum eller Kanban fungerer bedst: Scrum egner sig efter vores mening bedst til projekter, hvor opgaverne har en naturlig sammenhæng.
Kanban derimod egner sig godt til at håndtere en løbende proces, eksempelvis når projektet er sat i drift. Der kommer løbende mindre tilpasninger, rettelser, supportopgaver, bugs og så videre. Derudover kan projektet være et ud af flere projekter, der alle genererer løbende opgaver. Opgavernes manglende sammenhæng og forudsigelighed gør Kanban til et godt valg, når man gerne vil bevare overblikket over opgavernes status og sikre transparens i organisationen.
Vælg, hvad der passer bedst til din hverdag
Vi håber, at du har fået et overblik over forskellene på de to frameworks. Der er et ikke et, der er bedre end det andet – men der er helt sikkert et, der passer bedre til din hverdag end det andet.
Har du spørgsmål eller kommentarer, så skriv endelig til os! Og har du brug for et par gode råd og sparring om, hvordan du vælger det bedste framework til dit team og din hverdag, så tager vi gerne en uforpligtende snak om det over en kop kaffe og en telefon eller videomøde.
