Så löser du de 7 vanligaste Kanban-misstagen som förstör din utveckling

Det här passar perfekt om ditt team arbetar i situationer där det är viktigt att kunna reagera snabbt, till exempel inom kundsupport eller vid hantering av underhållsärenden.

Kanban kan upplevas som enklare än Scrum, eftersom du inte behöver följa den strikta och styrande strukturen i Scrums ceremonier. Men den här friheten gör det också svårare att lyckas riktigt bra med Kanban. Om du tror att Kanban kräver mindre disciplin har du fel – det kräver mer disciplin.

För att hjälpa dig att använda Kanban på rätt sätt och undvika att friheten leder till ineffektivitet ska jag nu dela med mig av några viktiga råd som sparar både resurser och bekymmer.

Principerna för bra Kanban

Genom att först följa de här generella principerna kan teamet undvika att gå alltför fel med Kanban.

1. Sätt och följ gränser för pågående arbete (WIP) i processens olika steg

2. För inte arbetet vidare i flödet om det inte finns tillräcklig kapacitet (om de efterföljande processtegen har nått sina WIP-gränser)

3. Definiera vad som krävs för att flytta arbete från en processkolumn till nästa

4. Kom också ihåg att integrera refinement, övergripande planering och lärande i era arbetssätt

De vanligaste problemen – och så undviker du dem

Efter att ha stöttat företag med Agile-arbete i många år har jag och mina kollegor sett det mesta. Nu vill vi dela med oss av de sju vanligaste Kanban-problemen och hur du löser dem. Läs vidare och undvik fallgroparna.

1. Du samlar på dig tickets

Kanban är en metod för att visualisera arbetsflödet. Den fungerar genom att begränsa mängden pågående arbete. Kanban kommer från Toyota Production System och bilfabriker. Om du arbetar i en bilfabrik kan du inte ta bilar från produktionslinan och ställa dem bredvid din arbetsstation. Du skulle inte få något gjort om din arbetsstation såg ut som en stormarknadsparkering.

Varför känner då mjukvaruteam att de kan arbeta annorlunda? Varför är det så vanligt att se en Kanban-tavla full av tickets?

Faktum är att WIP-gränser för processen är en av de Kanban-regler som oftast bryts. De flesta Kanban-team har inte ens någon WIP-gräns, och de som har det följer den sällan till punkt och pricka.

Gör så här i stället

• Det är svårt att följa en strikt WIP-gräns. Även om ni känner att ni inte kan hålla en gräns bör teamet åtminstone inse att mindre WIP är bättre.

• Se till att teammedlemmarna arbetar med en sak i taget och kontrollera hur de efterföljande stegen i processen ser ut innan ni påbörjar något nytt. Är det fullt längre fram i flödet? Undersök hur du kan hjälpa till i stället för att öka belastningen.

Det är svårt att följa en strikt WIP-gräns. Även om ni känner att ni inte kan hålla en gräns bör teamet åtminstone inse att mindre WIP är bättre.

Se till att teammedlemmarna arbetar med en sak i taget och kontrollera hur de efterföljande stegen i processen ser ut innan ni påbörjar något nytt. Är det fullt längre fram i flödet? Undersök hur du kan hjälpa till i stället för att öka belastningen.

2. Refinement saknas

I ett Scrum-team är regelbundna ceremonier standard. Regelbundna refinement-sessioner varje vecka är inget undantag. Med Kanban är ceremonierna inte längre givna. Rutinen försvinner.

Eftersom Kanban bygger på ett flöde av tickets är det alltför lätt att börja arbeta med en ticket som inte har förfinats.

Det leder till:

• Att arbetet påbörjas med alltför stora tickets

• Slöseri – arbetet flyttas till kolumnen ”pågående”, och teamet förlitar sig på att en enskild utvecklare förfinar ärendet samtidigt som hen börjar implementera det.

Att börja arbeta med alltför stora ärenden

Slöseri – arbetet flyttas till kolumnen ”pågående”, och teamet förlitar sig på att en enskild utvecklare förfinar ärendet samtidigt som hen börjar implementera det.

Gör så här i stället

• Inför regelbundna sessioner för backlog refinement, även för Kanban-team

• Säkerställ god disciplin kring ”Definition of Ready”

• Använd en Kanban-tavla för refinement, eller lägg till en kolumn för refinement på arbetstavlan för att synliggöra när ärenden förfinas

• Kräv storleksuppskattning och sätt storleksgränser innan nya ärenden påbörjas

Inför regelbundna sessioner för backlog refinement, även för Kanban-team

Säkerställ god disciplin kring ”Definition of Ready”

Använd en Kanban-tavla för refinement, eller lägg till en kolumn för refinement på arbetstavlan för att synliggöra när ärenden förfinas

Kräv storleksuppskattning och sätt storleksgränser innan nya ärenden påbörjas

3. Du fokuserar för mycket på utveckling

Kanban-team fokuserar vanligtvis för mycket på kolumnerna för utveckling och testning. De glömmer ofta att hålla demon eller att be om feedback från användare och andra intressenter.

I Scrum tvingar sprint review teamet att reflektera över resultaten och hur det påverkar backlogen och framtida planer att slutföra något. Demodelen i reviewn bjuder också aktivt in till feedback. Den här disciplinen saknas i Kanban och behöver återinföras i teamets kalender.

Gör så här i stället

• Schemalägg regelbundna demosessioner även för Kanban-team

• Överväg att lägga till en kolumn för ”feedback behövs” på din Kanban-tavla

• Var uppmärksam om teamet börjar fokusera för mycket på implementering och för lite på feedback

Schemalägg regelbundna demosessioner även för Kanban-team

Överväg att lägga till en kolumn för ”feedback behövs” på din Kanban-tavla

Var uppmärksam om teamet börjar fokusera för mycket på implementering och för lite på feedback

4. Du använder Jira:s standardworkflow

Jira:s standardworkflow ”Att göra” – ”Pågående” – ”Klar” bör förbjudas. Den har flera allvarliga problem, till exempel:

• Du kan inte se vilka ärenden som är nya och vilka som har godkänts av Product Owner för att ligga i backlogen. Product Owner måste ha kontroll över vilka ärenden som godkänns för backlogen. De behöver fatta ja- eller nej-beslutet och även placera ärendena i rätt prioritetsordning.

• Du kan inte ange om ett ärende behöver förfinas eller om det har förfinats och är redo att påbörjas (det vill säga uppfyller kraven i Definition of Ready). Om du bara använder ”Todo” som status för hela backloggen går det inte att styra förfiningsarbetet. Därför påbörjas arbetet ofta med oförfinade ärenden.

• Om ett ärende flyttas till Done antar man att arbetet är slutfört. Men du kan inte se om ärendet har demonstrerats, om du väntar på kundfeedback eller vilka ärenden som har releasats eller väntar på release. Hur hanterar du kodgranskningar eller designgranskningar?

Du kan inte se vilka ärenden som är nya och vilka som har godkänts av Product Owner för att läggas i backloggen. Product Owners måste ha kontroll över godkännandet av backloggen. De behöver fatta ja- eller nej-beslut och även placera ärendena i rätt prioritetsordning.

Du kan inte ange om ett ärende behöver förfinas eller om det har förfinats och är redo att påbörjas (det vill säga uppfyller kraven i Definition of Ready). Om du bara använder ”Todo” som status för hela backloggen går det inte att styra förfiningsarbetet. Därför påbörjas arbetet ofta med oförfinade ärenden.

Om ett ärende flyttas till Done antar man att arbetet är slutfört. Men du kan inte se om ärendet har demonstrerats, om du väntar på kundfeedback eller vilka ärenden som har releasats eller väntar på release. Hur hanterar du kodgranskningar eller designgranskningar?

Gör så här i stället

• Överväg följande processteg som kolumner på Kanban-tavlan: Nytt, Behöver förfinas, Redo för implementering, Granskning, Feedback behövs, Väntar på demo.

• Låt din Kanban-tavla spegla er verkliga process – det är precis vad Kanban handlar om!

Överväg följande processteg som kolumner på Kanban-tavlan: Nytt, Behöver förfinas, Redo för implementering, Granskning, Feedback behövs, Väntar på demo.

Låt din Kanban-tavla spegla er verkliga process – det är precis vad Kanban handlar om!

5. Du har inga regler för att flytta ärenden vidare i flödet

Bra Agile-team har två kvalitetskriterier: Definition of Ready (DoR) för att påbörja arbetet och Definition of Done (DoD) för att slutföra det. Dessutom diskuterar och fastställer välfungerande Kanban-team regler för att flytta ärenden från en Kanban-kolumn till nästa.

Använd en mini-DoD

I mitt senaste team som använde Kanban säkerställde utvecklaren till exempel följande när ett ärende flyttades från kolumnen ”Development” till ”Testing” :

• Funktionaliteten fungerar som önskat och enligt definitionen i acceptanskriterierna

• Utvecklarens egna tester godkänns och det finns inga kända buggar

• Koden kompileras utan varningar

• Enhetstester är genomförda och godkända

• Designdokumentationen är uppdaterad i Confluence

• Testinstruktioner finns tillgängliga för testingenjören

• Utvecklaren och testaren har ett överlämningssamtal

Funktionaliteten fungerar som önskat och enligt definitionen i acceptanskriterierna

Utvecklarens egna tester godkänns och det finns inga kända buggar

Koden kompileras utan varningar

Enhetstester är genomförda och godkända

Designdokumentationen uppdateras i Confluence

Testinstruktioner ges till testingenjören

Utvecklaren och testaren har ett överlämningssamtal

Med den här överenskommelsen (mini-DoD) minskade vi mycket av fram- och återkommunikationen mellan testare och utvecklare, vilket gjorde teamets arbetsflöde smidigare.

Tänk återigen på bilfabriken. Varje efterföljande arbetsstation måste kunna lita på att medarbetarna vid de föregående stationerna alltid utför arbetet på samma sätt.

Gör så här i stället

• Definiera mini-DoD:er för varje övergång mellan Kanban-kolumner

6. Du drabbas av ärendeblindhet

I Kanban är det lätt att fokusera för mycket på enskilda ärenden och tappa helhetsperspektivet. Under teamets dagliga möten berättar till exempel medlemmarna för varandra vad de arbetar med. När du sedan hamnar i en situation där teammedlemmarna borde förstå vad andra arbetar med, blir det tydligt att de inte har lyssnat.

Ärendeblindhet gör att varje teammedlem bara fokuserar på sina egna uppgifter.

Att samlas kring ett problem är ett kraftfullt sätt att lösa svåra problem. När människor fokuserar för mycket på sina egna ärenden kan de ibland missa situationer där teamet behöver samlas kring en fråga.

Ärendeblindhet är särskilt farligt när teamet till största delen arbetar på distans.

Kanban kan skapa silos kring enskilda personer

I Scrum behöver teamet tänka på sprinten och på vad hela teamet kan uppnå under sprinten. Därför är risken mindre att tappa bort andras arbete ur sikte. Sprintmålen hjälper också teamet att arbeta tillsammans.

Gör så här i stället

• Var uppmärksam på frågor som kräver att teamet samlas för att lösa dem

• Se till att din Product Owner hjälper teamet att förstå helheten och det kommande arbetet (backlog refinement och metoderna ”scan and plan” är till hjälp här)

• Håll regelbundna planeringsmöten med Kanban-teamet så att alla håller fokus på ett större mål

• Se till att deltagarna lyssnar under de dagliga mötena i stället för att dagdrömma

• Överväg att sätta månadsmål eller andra former av delmål för att hjälpa teamet att hitta rätt

• Var extra uppmärksam på att undvika silos kring enskilda personer i team som arbetar helt på distans

Var uppmärksam på frågor som kräver att teamet samlas för att lösa dem

Se till att din Product Owner hjälper teamet att förstå helheten och det kommande arbetet (backlog refinement och metoderna ”scan and plan” är till hjälp här)

Håll regelbundna planeringsmöten med Kanban-teamet så att alla håller fokus på ett större mål

Se till att deltagarna lyssnar under de dagliga mötena i stället för att dagdrömma

Överväg att sätta upp månatliga mål eller andra delmål för att hjälpa teamet att hitta rätt

Var extra uppmärksam på att undvika personberoende silos i helt distansbaserade team

7. Ni håller inga retrospektiv – och lär er därför inte

I Scrum har ni vanligtvis en viss rytm för retrospektiv. Den officiella Scrum-guiden säger att retrospektivet ska hållas under sprintens sista möte – men inget hindrar er från att hålla extra retrospektiv vid andra tillfällen. Experimentera och se vad som fungerar för ert team.

Utan den här rytmen kan Kanban-team lätt glömma att hålla retrospektiv.

Gör så här i stället

• Boka in regelbundna retrospektiv sex månader i förväg

• Ha dem minst en gång i månaden, gärna oftare

• Prioritera och håll fast vid retrospektivmötena – ställ inte in dem

Boka in regelbundna retrospektiv sex månader i förväg

Ha dem minst en gång i månaden, gärna oftare

Prioritera och håll fast vid retrospektivmötena – ställ inte in dem

Kanban som faktiskt fungerar

Kanban kan vara roligare och mer motiverande för ett team som arbetar i en mycket dynamisk miljö. Men även om Kanban kan verka enkelt bör ni inte ta det för givet. Bra Kanban kräver mer disciplin än Scrum. En bra Scrum Master hjälper Kanban-teamet att fortsätta förbättras.

Vi hoppas att den här listan med sju saker att undvika hjälper ert Kanban-team att förbättras.