Kanban bliver for tiden fremstillet af mange, som det helt nye, der kommer til at erstatte Scrum som den fortrukne Agile arbejdsmetode. Så nu spørger folk “skal vi vælge Kanban i stedet for Scrum?”

Tjah, skal vi have en pizza eller skal vi lytte til Mozart? I mine øjne er Kanban og Scrum to forskellige ideer, som ikke opererer indenfor samme felt.

Kanban arbejder med at optimere en lind strøm af produktionslignende opgaver, i bund og grund en operationel tilgangsmåde. Hvilket er yderst anvendeligt for uforudsete opgaver eller for en kontinuerlig strøm af arbejde med forholdsvis lille kompleksitet.
Scrum arbejder med at sætte grænser for udviklingen af nye produkter og tiltag med høj kompleksitet. Med andre ord for ting, hvor vi endnu ikke ved, hvordan vi skal udføre de enkelte tasks. Scrum definerer og hjælper me den nødvendige planlægningsdel i produktudviklingen og skabe en ramme, som guider teamet til faktisk at udføre arbejdet.


For mig er Scrum det forkromede overblik over, hvordan vi genererer værdi ud af indsatsen i organisationer. Vi kan benytte Kanban i Scrum Sprints, som en metodet til at udføre arbejdet.

Hvis Kanban bliver benyttet selvstændigt, og der kan være mange arbejdssituationer, hvor det er passende, så ser jeg Kanban som Scrum hvor Sprintet er reduceret til en enkelt dag eller helt skåret væk.

Folk, der er fortalere for Kanban fremfor Scrum, lovpriser ofte det faktum, at der ikke er de samme restriktioner og regler, man behøver ikke lave Sprints, man behøver ikke lave Estimation og man behøver ikke holde Retrospective møder. Jeg gad nok vide, om vi i virkeligheden ser udviklingsgruppernes gamle og velkendte modvilje mod organisation og begrænsninger, stikke sit hoved frem igen? Vi ønsker at gøre, hvad der passer os, når det passer os.

Fraværet af begrænsninger er i sig selv ikke noget positivt, vi er trods alt ikke i Height Ashbury i 67’ - “summer of love” - længere. Begrænsinger er afgjort nødvendige, hvis vi ønsker at få selv-organisering i teams til at blomstre op. For at man skabe en fælles forståelse omkring et produkt, er vi nødt til at have et fælles sprog, en klar vision, en rettesnor for hvilken retning, vi er på vej i, og så videre. Man kan sammenligne Scrum med trafikreglerne. Disse begræsninger fastlægger rammerne for at komme fra A til B og overleve opgaven.

Jeg vil prøve at uddybe dette.

Så hvad er Scrum egentlig?

Scrum er en filosofi, en måde at tænke på, en måde at angribe projekter og kampagner af en vis størrelse og kompleksitet på, så man opnår et nær optimalt resultat.

I hjertet af Scrum filosofien er tanken om konstant forbedring.

1. På det strategiske plan handler det om at finde værdi og omkostninger for del-leverancer (Product Backlog Items - PBIs), og at prioritere de del-leverancer, der er de bedste, vi kan vælge, til levering næste gang.
2. På det taktiske plan handler det om at sammensætte et Spritn med del-leverancer, der kan designes og nedbrydes til tasks.
3. På task planet (nogen gange omtalt som det operationelle plan) handler det om at benytte faktuelle færdigheder til at gennemføre tasks og sikre at disse er korrekt udført for at en del-leverance er “færdig”.

Oven over dette er den grundlæggende filosofi om gøre forhindringer og sten på vejen synlige, og tage hånd om dem i tide for at opretholde momentum og engagement.

Et sæt af afgrænsninger er implementeret i Scrum for at opnå de mål der er nævnt ovenfor:

1. Vi har et veldefineret “modus operandi”: Arbejdet opdeles i korte Sprints med jævnlig levering af afsluttede enkeltdele.
2. Vi har veldefinerede roller for ansvaret: Product Owner, Scrum Master og Team.
3. Vi har veldefinerede møder: Sprint planlægning (1 og 2 og nu også Estimering), det daglige Scrummøde, Sprint Review og Retrospective.
4. Vi har veldefinerede hjælpemidler: Produkt Backloggen med del-leverancer, Sprint Backlog (task board) med del-leverancer nedbrudt i tasks og en Impediment Backlog med de ting der lige nu forhindrer optimnal fremdrift..

Og hvad er Kanban så?

Kanban er i hovedsagen et avanceret task board, normalt med forskellige køer (states), hvor igangværende arbejde (WIP) skal passere igennem for at blive færdigt, arbejderne (teamet) trækker arbejde fra forangående køer. Hver kø har kun plads til en begrænset mængde af opgaver for at minimere antallet af igangværende opgaver (WIPs) og hermed skabes et harmonisk flow så man kan reducere leveringstiden.

Og det er det! Hvad angår resten af arbejdsdagens struktur er man overladt til sig selv.

Fordele, som der argumenteres for ved Kanban fremfor Scrum

Lad os nu kikke nærmere på de to metodikker for at se de fordele ved Kanban, som der ofte argumenteres for.

1. Begrænse igangværende arbejde (WIP)

Ofte fremhæves den primære fordel ved Kanban at være den udtrykkelige begrænsning af WIPs.
Det er allerede implicit med i Scrum, hvor vi har fokus på at få del-leverancer sat til “Done” så hurtigt som muligt. Ved at nedbryde opgaver i tasks, som normalt kun vil tage én dag at udføre får man et bedre overblik, og det hele er nemmere at arbejde med. Det er sandt at der ikke er nogen specifk begrænsning af antallet af WIPs i Scrum, selvom fortalere for Scrum fortæller folk, at de skal holde antallet af WIPs nede. Generelt falder det helt i tråd med Scrums ide, da det antages at Teamet har så meget overblik over arbejdet i et Sprint, at de er i stand til at håndtere denne kompleksitet, unden at der opstår spild. Ved at opdele arbejdet i enkelte Sprints reduceres den opfattede kompleksitet i Sprintet, så normalt vil dette ikke være et problem.


Faktisk skaber den udtrykkelige begrænsning af WIPs i Kanban et unødvendigt pres på folk. I stedet for at give folk en rettesnor til, hvordan de kan gøre deres arbejde, tvinger processen i Kanban dem til at udføre deres arbejde på én bestemt måde.

2. Afspejler de forskellige stadier af det igangværende arbejde

I Kanban er det normalt, at WIPs bliver opdelt i forskellige tilstande f.eks. “Design”, “Implementation”, “Test” med mere.

På den ene side kan dette være nyttigt, og Scrum siger ikke noget om, hvordan et Task Board eller en Sprint Backlog bør se ud. Alt, hvad vi kan sige, er, at Sprint Backloggen skal være der for, at teamet og Scrum Masteren kan følge udviklingen og gribe hurtigt ind, hvis noget er på vej til at gå galt.

På den anden side indvirker dette på de selve muligheden for at opnår selvorganisering i et “tværfunktionelt” team. Ved at definere disse tilstande, opfordrer man ikke folk til at påtage sig opgaver, som de ikke er vant til at udføre, men i stedet for forstærker man gamle vaner med specialiserede roller. Det opfordrer mere folk til at holde sig til det, de kender.

3. De manglende regler

Det hævdes, at eftersom Kanban kun fastsætter meget få ting, står alle frit stillet til at udvikle de strukturer, de har behov for. Enhver bør anvende de værktøjer, de selv finder brugbare.
Det ser jo fint ud! Men det er ikke sandt. Kreativitet har brug for grænser. Teams har brug for grænser. Scrum er et empirisk bevist udgangspunkt som alle kan forstå. Fuldstændig frihed er ikke en velsignelse, men en forbandelse. Ved at starte med med veldefinerede rammer (som Scrum er) kommer alle til at holde samme takt, og resten af organisationen kan forstå dette “projekt-sprog” - man behøver altså ikke opfinde den dybe tallerken hver gang.

I takt med at teams og organisationen vokser med opgaven, vil de helt sikkert fortage lokale tilpasninger og justeringer i forhold til det, der stod i deres Scrum lærebøger, men det er ikke det samme som at droppe alle grænser.

Følgerne af kun at tilpassse sig Kanban

Mit synspunkt er, at hvis man kun benytter Kanban begrænser man sit lederskab til det taktiske og task orienterede niveau. Alle strategiske opgaver og team problemer bliver der ikke taget hånd om - eller også bliver man nødt til at opfinde nogle ekstra ting ovenpå Kanban, som kan ordne det.

Kanban er tænkt til produktion, det virker godt til en konstant strøm af arbejde, hvor hvert stadie af arbejde er forholdsvist veldefineret. Et par eksempler til at forklare dette:

1. Kanban har ingen roller. Det, der virkelig skaber værdi i Scrum er, at alle spillere har veldefinerede ansvarsområder og tilhørende autoritet. Det er min overbevisning, at forbedringer opnået via Scrum, kommer overvejende fra de tre centrale roller (Product Owner, Scrum Master og Team), der alle er ekstremt fokuserede på deres arbejde og alle er fuldstændig sikre på, hvad der forventes af dem. Det forsvinder hvis man kun benytter Kanban.
2. Kanban har ingen Sprints, der er en kontinuerlig strøm. I Scrum skaber vi et simpelt og lokalt projekt Sprint for Sprint, hele projektet er måske stort og uoverskueligt, men for de næste to til fire uger, ved vi præcist .hvad der forventes af os, og hvad vi skal gøre, det er et simpelt mini-projekt. Det giver Teamet fred og frihed til at være kreative indenfor de givne rammer, og ikke mindst giver det resten af organisationen en klar forventning til det resultat, som man får leveret i næste Sprint. Dette forsvinder, hvis man kun benytter Kanban.
3. Kanban har ingen estimering. Estimering er den første etape i den fortsatte stræben efter en fælles forståelse af de ting, der skal leveres, det er selve grundlaget for at Teamet kan forpligtige sig til at levere specifikke og verificerbare del-leverancer i et Sprint. Estimering er også en del af det grundlag, hvorpå Product Owner foretager sin release planlægning og tilpasser projektet til resten af organisationen, med hensyn til at overholder deadlines m.m. Estimater er også værdifulde når Product Owner skal prioritere del-leverancer. Hvis han opdager, at en given del-leverance er meget kostbar, kan det være, at han overvejer situationen to gange, inden den bliver igangsat. Hvis Kanban benyttes alene, hvordan skal man så komme frem til et budget for en given del-leverance?
4. Kanban har ingen daglige Scrum møder. Det er der heller ikke brug, fordi alle arbejder i deres eget lille aflukke. Testgruppen tester, udviklerne udvikler osv. Eftersom Kanban ikke har Sprints, vil det eneste man kunne gøre på et dagligt møde være, at opdage forhindringer.
5. Kanban har ingen Retrospektive møder. Medmindre noget andet tager højde for dette, så ødelægger dette den konstante forbedringscyklus, Retrospektive mødet er stedet, hvor fakta om arbejdet bliver opdaget og drøftet, hvor større forhindringer bliver lagt frit frem, og hvor områder for forbedring bliver udpeget. Alt dette forsvinder, hvis man kun benytter Kanban.
6. Kanban har ingen Impediment Backlog. Det bliver ofte fremhævet, at én af de ting som virkelig kan forbedre folks engagement og velbefindende på jobbet er, at der bliver taget hånd om alle typer af forhindringer med det samme (det er det Scrum Masteren gør i Scrum). Folk oplever at deres arbejde bliver værdsat og er vigtigt nok til at andre (Scrum Masteren) gider fjerne de forhindringer, uanset hvad det er, som er i vejen for, at de kan arbejde optimalt. Dette forebygger frustrationer. Alt dette forsvinder, hvis man kun benytter Kanban.

Konklusion

Kanban som et selvstændigt værktøj egner sig til en stadig strøm af jobs, for eksempel i produktion eller i en support afdeling. I den type arbejde er Sprints som ofte ikke mulige at gennemføre, folk ved sandsynligvis ikke på forhånd, hvad der sker lige om lidt. Ofte er der heller ingen diskussion omkring business value og estimater af et bestemt job eller en del-leverance, det skal bare gøres. Hvis hoved-severen er gået ned, så få den i gang igen.

Scrum, på den anden side, handler om strategisk at vælge, hvad man skal gøre med de forhåndenværende ressourcer. Det er en måde at køre en organisation på, hvor der er konstante krav om udvikling og forandring. Det drejer sig om “hvad” og “hvorfor”, ikke “hvordan” som i Kanban.

Min påstand er at Kanban og Scrum arbejder i to forskellige verdener. Kanban handler om at slukke ildebrande, Scrum handler om at antænde ildebrande (men kun de rigtige naturligvis).

Kanban er en defensiv “modus operandi”, Scrum er den offensive.