Har du også prøvet Kanban?

Jeg faldt for nyligt over Triforks podcasts (episode 18 & 19), hvor Jesper Bøg interviewes om Kanban - han har i øvrigt også skrevet en glimrende gratis e-bog om emnet - hvilket ramlede fint ind i nogle af de spørgsmål, jeg havde stillet mig selv (og stakler, der kom forbi), om hvad formålet er med nogle af de måder, vi gør tingene på.

  • Hvad får vi egentlig ud af at lægge opgaver ind i sprints?
  • Hvorfor har vi ikke bare en prioriteret to-do-liste?
  • Hvorfor er det så forbudt at ændre på et sprint, der er i gang - hvad nu, hvis vi bliver klogere undervejs, eller der kommer noget vigtigere ind fra højre?
  • Har vi nogle flaskehalse undervejs? Det er jo meget fint, hvis udviklerne er hurtige til at fikse fejl eller tilføje features, men hvad nytter det, hvis issues venter længe på at blive reviewet eller testet?

Især hvad angår bugs har det længe været mig en gåde, hvorfor det skulle være bedre at lade folk fikse de bugs, vi troede var mest vigtige for en uge siden, fremfor dem som vi hørte Supporten græde over i telefonen i går. Samtidigt er det ikke helt nemt at gætte (uden at skulle bruge ret meget tid på selve estimeringen, i hvert fald) hvor mange bugs vi kan nå at fikse i denne uge, resulterende enten i en stak issues, der blev overført til næste sprint (fy) eller sprints der fik tilføjet ekstra issues undervejs (fy fy).

En valid pointe i Scrum er, at udviklingsteamet skal kunne arbejde nogenlunde uforstyrret undervejs i sprintet, men i og med at vi i forvejen har timeboxet vores bug-fixing til én dag om ugen, er det ikke mere forstyrrende at skulle tage det ene eller det andet issue, når det bliver fredag.

Så for vores bug-fixing-fredage har vi nu forsøgsvis skiftet Scrum-boardet ud med et Kanban-board. Derved indeholder “To Do”-kolonnen nu også alle backlog-issues’ene i prioriteret rækkefølge, og der er kommet øvre grænser på de kolonner, hvor vi har igangværende arbejde, dvs. for vores vedkommende “In Progress”, “Ready for Review” og “Ready for Test”.

Illustration: Privatfoto

Lige nu er det tydeligt på vores board, at vi har for mange issues i “Ready for Test”. Jesper Bøg havde en interessant - og måske lidt kontroversiel - kommentar i en af podcasts’ene, nemlig at det var bedre at arbejde på noget, der var vigtigt, end noget man var god til. Altså: Hvis vi har for stor en test-backlog, så giver det nok mere værdi for virksomheden at udviklerne også hjælper til at få denne nedbragt, end at man sub-optimerer ved at alle skomagerne bliver ved deres læst.

Kanban er naturligvis meget mere end bare et board med grænser på kolonnerne. Vigtige pointer, som jeg ser det, er bl.a. fokus på hele værdikæden - her kunne vi godt have mere med i det visuelle flow, f.eks. på venstresiden omkring prekvalificering og udvælgelse af issues samt release-nære aktiviteter på højresiden, og løbende nedbringelse af gennemløbstiden for issues. Men ikke mindst er Kanban også en metode til kontinuerlig forandring og forbedring af vores processer - og der er vi jo kun lige startet.

Har du/I gjort jer eksperimenteret med brug af Kanban, og hvad er dine erfaringer med at bruge Kanban som en del af en softwareudviklingsproces? Er Kanban “det nye Scrum” eller fis i en hornlygte?

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Søren Malling

Jeg blev præsenteret for kanban i Tyskland i forbindelse med et Open Source projekt.

Jeg blev rigtig glad for det "loft" der var på de forskellige kolonner og den måde at det fik holdet til at hjælpes ad, med at få testet ting, når der lå for meget "til test".

Det kræver hold- og personlig-disciplin, at bevæge sig væk fra det man er god til og i stedet gøre det vigtige, men man ser det batte positivt, når de andre fra holdet gør det samme.

  • 1
  • 0
Casper Bang

Nu er jeg bare alm. dødelig udvikler, det primært kører i Sprints, og ellers i Kanban forløb når vi er i "maintenance-mode". Derfor tænker jeg således:

Hvad får vi egentlig ud af at lægge opgaver ind i sprints?

Man får en fokusering og commitment begge veje - nu er det dét her vi gør, project owners skal have gjort deres benarbejde i forbindelse med stories, og udviklere skal acceptere opgaverne med målbare/objektive test/done kriterier.

Hvorfor har vi ikke bare en prioriteret to-do-liste?

Fordi software har en høj kompleksitet og udvikling en stor berøringsflade på tværs af decipliner, der sjældent mapper så simpelt. TODO-lister er godt til gøremål før en ferie, checkliste før take-off mm.

Hvorfor er det så forbudt at ændre på et sprint, der er i gang - hvad nu, hvis vi bliver klogere undervejs, eller der kommer noget vigtigere ind fra højre?

Fordi hele ideen er "commitment", og man vil undgå at ting trækkes i langdrag - udviklere kan sagtens bruge uger på at polere på noget uden det nødvendigvis er det vigtigste (Parkinsons Lov). Hvis der er usikkerheder, påregnes dette ved planning eller man planlægger en timeboxed analyse-fase. Går det helt galt og/eller kommer noget ind fra højre, så kan man altid aborte.

Har vi nogle flaskehalse undervejs? Det er jo meget fint, hvis udviklerne er hurtige til at fikse fejl eller tilføje features, men hvad nytter det, hvis issues venter længe på at blive reviewet eller testet?

Det handler vel mere om planlægning samt process-, kvalitet- og release-strategi. Dét er bestemt tricky, men jeg skulle alligevel mene det er bedst understøttet af Scrum.

Der er nok bare ikke ret mange organisationer der kan køre Scrum hele tiden, men i en kaotisk verden hvor det ene yderpunkt hedder vandfald og det andet hedder TODO/cowboy, synes Scrum at være et godt kompromis.

  • 4
  • 0
Rasmus Schultz

I min erfaring er den bedste model en hybrid model - vandfald og DDD fungerer fint som første fase i et projekt, og når mindstekravene så er mødt, er det tit en stor fordel at bruge en agil model (af en eller anden slags) til fortsat udvikling.

Hvis man arbejder i en virksomhed der reelt kun udvikler ét produkt, kan man stadig godt bruge en hybrid model - det er bare et spørgsmål om at identificere under-projekter, og behandle dem som særskilte, nye projekter.

En model der udelukkende er baseret på en agil metode, lyder som en opskrift på kaos i mine ører - men det er så bare min opfattelse, jeg kan ikke sige at jeg har prøvet det; dog har jeg haft en del jobsamtaler det sidste års tid, og fik meget indtryk af, at der ikke rigtig er plads til (eller brug for) system udviklere eller arkitekter som mig, på de arbejdspladser der udelukkende kører agil.

Casper, hvordan håndterer i større nye krav? Ting der ikke passer størrelsesmæssigt i et sprint? Det er jo ikke alting der (med fordel) kan brydes ned til små håndterbare stykker - hvad gør i, når i løber ind i et helt nyt og betydeligt større krav? (man kan jo være så heldig, at arbejde et sted, hvor det aldrig sker, men det lyder usandsynligt for mig.)

  • 1
  • 0
Casper Bang

Casper, hvordan håndterer i større nye krav? Ting der ikke passer størrelsesmæssigt i et sprint? Det er jo ikke alting der (med fordel) kan brydes ned til små håndterbare stykker - hvad gør i, når i løber ind i et helt nyt og betydeligt større krav?

I vores verden, kan alt brydes ned - også selv om det måtte betyde at slutresultatet af et sprint er af en imaginær størrelse (nye krav, andre krav, research, løsningsforslag, valg af værktøj, møde med konsulent, formatbeskrivelser, interfacebeskrivelser, test-plan, arkitektur etc.).

Den klassiske debat imellem vandfald og agile afhænger nok meget af hvilken biks man sidder i. Der er jo kolosal forskel på at sidde som in-house udvikler i en lille viksomhed (hvor software i princippet er sekundært) vs. at sidde i et decideret softwarehus (Microsoft, Systematics, KMD etc.). Derudover er der jo også stor forskel på om der er tale om at udvide et legacy system eller bygge noget helt nyt - det sidste er jo klart det nemmeste og sjoveste, især for en arkitekt! ;)

Pointen med Scrum er bare, at det skal være synligt hvad der foregår og at der skal være flow i tingene. Jeg tænker på det som "tracer-bullets", hvor man godt kan tillade sig at skyde lidt til højre og venstre, hvis man så samtidig er blevet så meget mere klar over hvor det egentlige mål befinder sig.

  • 1
  • 0
Peter Sepstrup

Vi har haft stor succes med at flytte så meget så muligt af vores akut drift ud i et drift team, så vores dev-teams vitterligt kan arbejde uforstyrret. Det har givet et helt andet fokus på nyudvikling. Vores drift hold køre en form for Kanban nu og vi har netop besluttet at sende folk på kursus for at få det fulde udbytte.

I forhold til at bryde ting ned til sprints, så har vi også succes med at bryde alt ned. Det kan give et overhead at bryde ting ned i mindre bider hvis de skal være uafhængige, men det er min erfarring at store opgaver alligevel eksplodere når de startes op. Derfor ender det umiddelbare overhead ved opsplitning med at være et mere realistisk estimat.

  • 1
  • 0
Lars Meldgård

Vi har prøvet Kanban og har erfaret at nogen kan komme til at "putte" med opgaverne, idet der ikke er et indbygget incitament til at nå en deadline - ligesom man har i Scrum. Med incident håndtering er det selvfølgelig umuligt at planlægge inflow, så ideen med at have prioriteret liste er god nok. Men sammensætning af kompetencerne i dit team er kritisk, og folk skal overholde aftalerne.
Ikke mindst så fratager Kanban dig ikke for opfølgning af de enkelte opgaver, og det vil stadig være anbefalelsesværdigt at gøre start/slut dato synlig for at sikre fremdrift eller muliggørelse af at "swarme" for at hjælpe en besværlig opgave frem.

  • 0
  • 0
Log ind eller Opret konto for at kommentere