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”.
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?
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
