Kanban er en gammel teknik der stammer fra Japan. Ordet betyder noget i retning af “skilt” eller “signal”. I 1700-tallet brugte japanske producenter Kanban til at markedsføre sig, i det de placerede små logoer udskåret i træ på deres varer, så folk kunne se hvilken smed eller snedker der havde lavet varen.

Ordet har sidenhen fået ny betydning, specielt efter Taiichi Ohno og David Andersen publicerede hver deres bog omkring produktivitet i henholdsvis bilindustrien og softwareindustrien. De fleste i softwareindustrien kender Kanban som et whiteboard inddelt i felter med påklistrede post-its som repræsenterer opgaver.

Kanban er et værktøj. Det betyder basalt set at sætningen “vi kører Kanban” giver ligeså meget mening som en tømrer der siger “jeg kører sav”.

Hvis man ønsker at få et visuelt overblik over opgaver, deres status og arbejdsbyrde i et team; så kan Kanban være det rigtige værktøj. I Lean-terminologi er et Kanban board sammenlignligt med et Lean-board der anvendes til daglig driftsledelse.

Jeg har oplevet mange frustrationer hos teams der “kører Kanban”, de primære årsager skyldes:

• Prioritering
• Planlægning
• Opgave “tilblivelse”
• Opfølgning

Teorien omkring Kanban i softwareindustrien nævner ikke de ovenstående punkter, udover at det er en forudsætning for optimal implementering.

Opgaver bliver skabt “on demand” og ankommer i sekventiel, prioriteret, rækkefølge således at teamet er i stand til at eksekvere.

En gylden regel ved implementering af Kanban er “garbage in, garbage out”. Hvis teamet ikke har styr på de ovenstående punkter inden de starter med Kanban, så har de det heller ikke efterfølgende. I kontrast kan det nævnes at deciderede process frameworks som Scrum og Waterfall adresserer disse punkter og derfor ikke helt samme børnesygdomme.

Et setup jeg har haft stor success med i forbindelse med indførsel af Kanban er følgende:

1. Definer en product owner for teamet, med ansvar for opgave “tilblivelse” og prioritering
2. I samarbejde med product owner og projektleder udarbejdes en langsigtet release plan, som evt. brydes op i inkrementer (aka sprints)
3. Afhold daglige standsups hvor der laves opfølgning
4. Afhold ugentlige/månedslige projektstatusmøder hvor den langsigtede plan og den kortsigtede eksekvering bliver alignet
5. Afhold retrospektives med fast interval