Så undviker du att överbelasta din Kanban med för mycket pågående arbete

Detta kallar Kanban begränsningar för pågående arbete (WIP), och de är helt avgörande för bra Kanban.

Teamet kan till exempel bara ha 5 ärenden under utveckling eller 3 ärenden under testning samtidigt. Om WIP-gränsen nås bör teamet inte kunna föra arbetet vidare förrän den arbetsfas som begränsar flödet har avlastats.

Kaoset utan WIP-gränser

Utan WIP-gränser kan teamet lätt börja samla på sig för mycket pågående arbete. När det finns för mycket arbete på tavlan:

• Blir det svårt att förutse eller hantera arbetsflödet.

• Blir det många uppgiftsbyten och mer stress.

• Teamet tvingas utveckla sätt att få igenom brådskande arbete i en annars igensatt process. Det kan leda till prioritering enligt principen ”den som skriker högst vinner”, vilket inte är ett beteende du vill lära resten av organisationen.

De flesta Kanban-team sätter dock inte några strikta WIP-gränser. Och de team som gör det slutar ofta att följa dem.

Föreställ dig en fabrik i stället för en mjukvaruutvecklingsprocess

Föreställ dig en annan, mer traditionell typ av arbete. Titta på en liten fabriksverkstad som tillverkar fysiska produkter. Produkterna byggs vid flera olika arbetsstationer. Stegen kan vara:

• Bearbetning

• Målning

• Montering

• Slutlig kvalitetskontroll

Föreställ dig att ett problem uppstår i det sista monteringssteget. Produktionslinjen måste av någon anledning stoppas. Det kan bero på fel i komponenter från tidigare steg eller på att produktionslinjens verktyg har gått sönder. Vad skulle hända ute på fabriksgolvet?

Jag är ganska säker på att operatörerna vid målnings- och bearbetningsstationerna skulle få veta det om problemet kvarstod längre än några minuter. Skulle de fortsätta arbeta som vanligt vid sina stationer och fylla fabriksgolvet med halvfärdiga komponenter?

Det vore ganska absurt. Det skulle vara fullständigt meningslöst att fortsätta arbetet i de tidigare stegen när arbetet inte flyter vidare i de efterföljande stegen. Det skulle dessutom bli fysiskt omöjligt – det skulle inte finnas plats på fabriksgolvet för att lagra de ofärdiga komponenterna.

Om möjligt skulle operatörerna förstås försöka felsöka och åtgärda produktionslinjen så snart som möjligt.

Varför fungerar inte samma sunt förnuft i Kanban för mjukvaruutveckling?

Inom mjukvaruutveckling är arbetsobjekten inte fysiska. Om det uppstår problem i de efterföljande arbetsstegen minskar inte kontorsutrymmet. Utvecklarna kan fortfarande föra arbetet vidare.

Det är precis därför Kanban har WIP-gränser. De är virtuella begränsningar som ska synliggöra flaskhalsar i processen. Om du helt bortser från dem – eller inte har några WIP-gränser alls – är du som de omedvetna fabriksarbetarna som blint fortsätter att fylla fabriksgolvet med ofärdigt arbete.

Varför är det lättare att bortse från WIP-gränser i IT-arbete? Det kan bero på följande:

• Arbetsärenden är mer abstrakta än fysiska objekt

• Vi förstår eller respekterar inte fullt ut arbetet i efterföljande steg

• Vi arbetar inte som ett team – vi fokuserar bara på vårt eget processteg

• Vi mäter inte arbetsflödet med DevOps-mått som cykeltid

• Vi vill instinktivt ”vara effektiva” och framstå som upptagna på jobbet

Motstå behovet av att framstå som ”effektiv”

Effektivitet är ett mått för situationer där du arbetar med ögonbindel. När du inte vet hur arbetet flödar genom teamets process fokuserar du naturligtvis på att arbeta så snabbt och effektivt som möjligt med din egen uppgift.

Kanske har du en instinkt att ”vara effektiv och upptagen”. Vad gör du när chefen är i närheten? Alla beter sig upptaget! Är den här typen av beteende ett resultat av att vi vill framstå som en värdefull del av teamet?

Vad du kan göra för att lösa situationen

Hur kan vi få teamet att förstå värdet av arbetsflöde och att begränsa pågående arbete? Jag tycker att vi bör

• Mäta arbetsflödet fram till ”Done” och experimentera med strikta WIP-gränser

• Vidta åtgärder för att minska effekten av begränsningar och flaskhalsar

• Lära känna andra arbetssteg bättre – byt roller

• Teambuilding – lär känna varandra, så känner du ett större behov av att hjälpa andra teammedlemmar när de behöver det

Mät arbetsflödet fram till Done

Scrum Master kan mäta teamets veckovisa velocity. Till exempel kan hen varje fredag räkna hur många ärenden som nådde kolumnen Done under veckan. Sedan kan hen komma överens med teamet om ett experiment: Under följande vecka följer teamet strikt en uppsättning WIP-gränser. Därefter mäts mängden färdigställt arbete igen samma fredag.

Teamet bör sedan diskutera hur WIP-gränserna ska ändras för nästa vecka. Jag garanterar att det skulle öka takten. Det är oundvikligt. I kombination med att dela upp arbetet i mindre delar borde detta tillvägagångssätt finnas i varje ”Kanban-mästares” kokbok.

Var medveten om begränsningar

Teamet har en flaskhals. Varje process i världen har en, och teamet har också en. Vad är det? Är det testning? Automatiserad testning? Godkännande från kunden? Teamets Scrum Master måste ställa frågan, och teamet måste vara medvetet om flaskhalsen.

Nästa fråga är hur mängden arbete som flödar genom flaskhalsen kan ökas. Till exempel:

• om flaskhalsen är automatiserad testning: hur kan skapandet och körningen av testerna gå snabbare?

• Om flaskhalsen är kodgranskningar: vilka regler kan teamet införa för att experimentera med att snabba upp granskningen av andra utvecklares pull requests?

Få bättre förståelse för hela processen

Om problemet med för mycket WIP beror på att teamet inte känner till eller respekterar andra steg i processflödet, kanske det är dags att byta roller ett tag. Låt utvecklare testa under en period, och låt testare parprogrammera med en utvecklare.

Jag tror också starkt på att traditionell ”teambuilding”, där teammedlemmarna lär känna varandra bättre, hjälper till att skapa respekt för andra. Är ni en grupp eller ett team? Prata om annat än arbete och lär känna personen bakom rollen.

Jag hoppas att den här bloggen har fått dig att fundera på att införa WIP-gränser i ditt team. Lycka till med att begränsa pågående arbete!