Mjukvaruprojekt med Kanban

Kanban är ett sätt att visualisera projektarbetet och det är enkelt att komma igång med. Det enda som behövs är post-it-lappar och en whiteboard som sitter centralt så att alla kan se den och så att alla ryms kring den. Kanbantavlan används sedan som ett visuellt projektledningsverktyg genom hela mjukvaruprojektet.

Kanbantavlans delar

Backloggen

Första delen av Kanbantavlan består av en Backlog. Det är en lista på alla saker som behöver göras. Varje sak som skall göras skrivs på en Post-it-lapp och placeras i Backloggen på Kanbantavlan.

Ett antal steg

Resterande delar av tavlan består av ett antal steg motsvarande de steg som du tar i din utvecklingsprocess. Föst väljer du en uppgift som skall göras från Backloggen, d.v.s du väljer en Post-it-lapp från Backloggen. Denna lapp skall sedan förflyttas genom varje steg som finns på tavlan. När Post-it-lappen når tavlans slut är funktionen redo att levereras eller driftsättas. Stegen kan t.ex. vara:  "Specificera arbetet", vilket  innebär att bryta ned uppgiften i mindre hanterbara bitar. Uppgifterna som står på lapparna i Backloggen  är oftast alldeles för stora och dessa måste  brytas ner. Nästa steg är att "Göra det" eller  "Implementera det". Och när du väl gjort det blir sista steget att "Verifiera" resultatet innan det levereras till kunden.

Pågår-Klar-kolumner

Varje steg har har en Pågår-kolumn och en Klar-kolumn. Dessa visar vad jag jobbar med nu och vad jag är klar med. Detta är viktigt i Kanban eftersom varje uppgift i Kanban blir klar stegvis och inte i slutet. En anledning till att Klar-kolumnen finns i Kanban är att du verkligen måste tänka till om du verkligen är klar eller ej. Du skall inte flytta lappar hip som hap mellan kolumnerna på tavlan. 

Klar - regler

Varje steg i Kanbantavlan, förutom den första som består av Backloggen, är indelad i kolumnerna Pågår och Klar. Så fort en Post-it-lapp med en uppgift flyttas in till ett nytt steg, t.ex. Implementationssteget, så sätts den i "Pågår". När den är klar flyttas de sedan till "Klar" och väntar där tills den får flyttas in till nästa steg. Men hur vet man när den är klar?

Innan en lapp flyttas från "Pågår" till "Klar" i ett steg så måste arbetet först ha uppfyllt vissa kriterier. Dessa bestäms av dina Klar-regler. Varje steg skall ha sina eget Klar-regler. T.ex. kan reglerna för Specificera-steget säga att "uppgiften skall ha brutits ned i mindre uppgifter som är på mellan 1-3 dagar". Reglerna för Implementationssteget kan vara "kodgranskning gjord, enhetstestning utan fel, integrerad, koden är incheckad osv". Exempel på reglerna för Verifieringssteget kan vara: "Arbetet är satt i produktion i en liten skala, validerad att inga problem uppstod, testad av verklig användare, alla synpunkter lösta osv".

Innan en lapp flyttas från vänster till höger skall någon i teamet kontrollera att Klar-reglerna är uppfyllda. Klar-reglerna kan stå på tavlan direkt efter kolumnerna eller längst ned under respektive kolumn som reglerna gäller för.

WIP-lements

WIP står för Work In Progress och det är ett arbete som pågår men som inte är klart ännu. En Post-it-lapp är ett WIP.

WIP-lements är en siffra som anger det maximala antalet post-it-lappar det får finnas i varje steg.

Varje stegs WIP-lement noteras i varje steg. Siffran säger att det inte får finnas fler lappar/uppgifter totalt i detta steg, dvs sammanlagt i "Pågår" och "Klar"-kolumnerna. Ett undantag är sista kolumnen där siffran endast säger hur många uppgifter som får finnas i "Pågår"-kolumnen. I sista kolumnen får det finnas hur många som helst i "Klar". Wiplementen begränsar alltså arbetet vi arbetar med i varje steg.


Hur man bestämmer dem går vanligtvis till så att man börjar med steget som tar längst tid. Vanligtvis är det "Implementations"-steget. Fundera ut hur många Work In Progress (WIP) som får finnas där. Antalet beror på hur många team-medlemmar det är i projektet.  Man vill att  antalet WIP skall vara ganska lågt, så att arbetet går lätt och flyter på utan stress och utan att någon behöver jobba över, men det skall vara tillräckligt högt för att vi skall får saker gjorda. Sätt  tex 2-3 st per person. En person vill troligtvis inte ha färre än två uppgifter åt gången. Anledningen är att om du kör fast i en uppgift så kan du hoppa till den andra uppgiften.

Nu när du bestämt maximala antalet uppgifter i det största steget kan du börja matcha antalet WIP i de övriga stegen så att flödet genom Kanbantavlan får ett jämnt flöde.

Om arbetet går för fort genom det första steget blir det stockning innan nästa steg. Detta är ett tecken på att du  har för mycket jobb igång och om någonting ändras i projektet (t.ex. nya krav och nya behov hos användaren tillkommer, akuta buggar upptäcks) så är det besvärligt att ändra kurs snabbt. Risken med att ha för många samtidiga uppgifter i ett steg är att du har jobbat med sex sju uppgifter i ett par veckor och upptäcker att hälften skall slänga bort för att de blivit inaktuella nu.

När hastigheten genom tavlan är ganska konstant har vi hittat de mest optimala antalet WIP:s för varje steg.

Det finns modeller för att trimma antalet WIP i varje steg. I boken "Agile Project Management with Kanban" av Eric Brechet" finns ett enkelt kalkylblad för att hantera detta.

Beroenden och blockeringar

Arbeten som beror på andra arbeten, på andra team eller externa parter kan bli blockerade. Du kanske bara har en enda person som kan åta sig just den uppgiften men personen är upptagen med annat  just nu. Du har en WIP, du har en post-it-lapp, men den är blockerad på grund av att vi väntar på någon eller något. Alla känner igen det. En eller flera uppgifter har blivit blockerade. Vi måste hålla koll på dessa på något vis, så att arbetet kan återupptas så fort blockeringen upphört.

Ett sätt att hålla koll på blockerade WIP:ar är att lägga till en ny kolumn i mitten av steget och kalla den nya kolumnen "Håll koll", "Uppsikt" eller "Track". Sätt den blockerade post-it-lappen där och håll koll på den. Vid stand-up så ser alla kring tavlan vilka WIP:ar som är blockerade och alla kan diskutera kring dem.  "Har någon hört hur det går med..., hur går det för dig..., är du klar snart...jag är klar nu och kan börja med det idag...".

Så fort blockeringen är löst flyttas lappen ut igen till "Pågår"-kolumnen igen och ingår i WIP-lemensberäkningen igen. Men om det då är för många lappar i "Pågår" så får den vänta tills det blir ledigt, men så fort det är ledigt så hoppar den ut dit. Man kan tänka att lappen redan har högre prioritet än lappar som vill in från vänster,  eftersom den blockerade lappen redan har varit där tidigare. Det var bara det  att den var blockerad ett litet tag.

Det finns såklart bautastora blockeringar som kan kommer att blockera en  WIP:s i flera månader. Då är det inte lämpligt att ha den i "Track"-kolumnen. Om en lapp sitter där vecka efter vecka och månad efter månad så blir den tillslut ignorerad. Sådana stora blockeringar blir ett projektledningsproblem.

Blockeringar som beror på att bara en enda person sitter på en viss kunskap, eller blockeringar som beror på semestrar, sjukskrivningar, wabbningar o.s.v.  kan förebyggas genom kunskapsspridning i teamet. Försök att inte alltid ge arbetsuppgifter till personen som är stjärna på just den uppgiften. Ge uppgiften till någon annan och låt stjärnan fungera som stöd och mentor istället.

Prioritering av Backloggen

De flesta som arbetat med Backloggar vet att den blir väldigt lång tillslut. Antalet lappar till vänster på tavlan bara växer och växer. Hur skall man kunna sortera dem? Det vanligaste sättet är att Backloggen sorteras genom att sätta de viktigaste lapparna högst upp och de minst viktiga längst ned. Detta rekommenderas i t.ex. Scrum. Det kan fungera väldigt bra. Nackdelen är att när man måste göra omprioriteringar  i projektet (vilket alltid sker) så kan de ta onödigt lång  tid och kännas jobbigt att behöva möblera om alla lapparna på tavlan. Det blir ett hinder. Kanske var det av denna anledning som de, på en arbetsplats jag arbetat på, valde att sortera Backloggen i bokstavsordning, vilket innebar att det inte alls fanns någon logisk ordning bland uppgifterna. Mängder av lapparna blev sittandes i månader utan att det ens diskuterades kring dem.

Ett mycket enkelt sätt att hantera Backloggen på Kanbantavlan är att placera alla lappar som hänger ihop tillsammans i grupper.  Klumpa ihop dem och ha i åtanke "vad skall vi göra sedan".

Varje dag när teamet står vid tavlan och pratar så tittar alla på lapparna, diskuterar med varandra, pratar om lapparna, prioriterar, flyttar runt lapparna osv. Till skillnad mot Scrum så behöver vi i Kanban inte svara på frågorna om vad vi gjorde igår, vad vi skall göra idag och om det finns några hinder. Detta framgår redan av Kanban-tavlan. Det vi talar om kring tavlan är snarare frågor som "Är det någonting som skall läggas till?" och "Behöver vi prioritera om?"  och sedan möblerar vi om lapparna lite snabbt.

Om en kund eller intressent ställer sig framför tavlan kan de enkelt se våra prioriteringar. Säljaren kan säga "Nä hörrni, det är väl viktigare med x än y, kan ni ändra det?". Det är inte komplicerat alls. Det är visuellt och enkelt.

I Scrum är prioriteringarna ganska fixa. Det måste vara så eftersom man jobbar med ett visst antal uppgifter i tidsbegränsade sprintar i Scrum. I Kanban finns inga time-boxar. Det finns istället ett kontinuerligt flöde och man kan leverera varje dag om man så vill. Microsoft levererar nya uppdateringar till sin X-Box varje dag till exempel och det kan de kan göra eftersom de arbetar med Kanban.

Planering och Estimering

Vi har kunder, intressenter och partners (interna och externa) som behöver veta när vi blir klara med saker och ting. De vill kunna planera sitt arbete och kommer med jämna mellanrum att fråga oss när vi blir klara med saker och ting. Det är viktigt att öven i Kanban planera på en hög nivå och att göra estimeringar. Detta kan göras på många sätt t.ex. med Story-points och det är ett alldeles utmärkt sätt att esimera.

På Kanbanvis är det rätt fram att esitmera. Man räknar helt enkelt hur många post-it-lappar, dvs uppgifter, som flödar ut från sista steget på Kanbantavlan  inom en viss tidsperiod, t.ex.  3 - 4 veckor.  Dela antalet lappar som flödade ut med antalet dagar som du räknade över. Detta ger hur många WIPs som teamet gör per dag (benämns som task completion rate).

För att räkna ut när en  viss arbetsprodukt kommer att bli klar så räknar vi först det totala antalet WIP:s för denna arbetsprodukt delat med task completion rate. Totala antalet WIP:s för arbetsprodukten räknas genom att addera

  1. Antal post-it-lappar i backloggen, men dessa är oftast större än en WIP och kommer att brytas ned då den flyttas in i det första steget.  Den behöver en estimering som är intuitiv. Håll upp lappen och fråga alla "om vi skall bryta ned denna hur många post-it-lappar, dvs WIP:ar, tror vi att det kommer att bli?". Folk kan gissa det ganska lätt. Om det verkar svår att intuitivt gissa hur många det blir finns det olika tekniker för detta som till exempel "playing poker"
  2. + Antal post-it-lappar i alla "Pågår"-kolumner på tavlan
  3. + Antal post-it-lappar som är "Blockerade"

Exempel: säg att en kund ringer och undrar när de kommer att få  orderformuläret till deras hemsida levererat. Vi tittar på Kanbantavlan och ser att i gruppen "orderformulär" finns  2 Post-it-lappar i Backloggen. Teamet tror att dessa två lappar kommer att resultera i 5 WIP:s. Vidare ser vi att teamet har  2 pågående WIP:s och 1 WIP som är blockerad. Det blir 8 WIP:s. Säg att WIP:s per dag för teamet är 2. Då beräknar vi 8/2 = 4 dagar. Tid kvar för att färdigställa en grupp av WIP:s = Totalt antal WIP:s för gruppen / Tid per WIP

Litteratur

Om du vill veta mer om Kanban rekommenderar jag boken "Agil Project Management With Kanban" av Eric Brechner.

Scroll to top