Introduktion till Kanban och hur det gynnar mindre IT-företag

Visionmate grundades för snart 2 år sedan. Vi har under hela tiden jobbat med att implementera nya verktyg och metoder för att leverera överlägsna tjänster men också för att upprätthålla integriteten inom teamet.

Målet är att alltid förbättras – annars försämras kvaliteten på grund av entropi.

Varför Kanban?

När vi började växa ordentligt under 2018 så behövde vi snabbt hitta lösningar för att hantera arbetsbelastningen på våra projekt. Efter en del research så blev de självklara kandidaterna Scrum och Kanban. Efter att ha undersökt båda metoderna så beslutades att Kanban var mer lämpligt för organisationens krav. Det främst beroende på att vi inte har fasta datum för release och att cyklerna då inte skulle vara lika effektiva. Det kontinuerliga Kanban-flödet var definitivt mer tilltalande.

De strategier som beskrivs här är baserade på “Kanban: Successful Evolutionary Change for Your Technology Business” av David James Anderson – med ändringar som passar vår organisation.

Vårt verktyg för att hålla reda på alla issues (ärenden) är JIRA, och vi använder samma system för våra Kanban-boards. JIRA är vidare länkad till GitHub, så vi enkelt kan spåra alla grenar för att se till att arbetsflödet är korrekt.

Det bör noteras att våra Kanban-implementeringar är ett konstant pågående arbete – vi försöker hela tiden identifiera eventuella problem och förbättra arbetsflödet.

Lägg också till att vi är spridda över 2 länder (lyckligtvis i samma tidszon), vilket nu underlättas av ett lättillgängligt molnbaserat system för alla anställda, det sänker kostnaderna snarare än att öka dem.

Fördelar med Kanban för Visionmate 

• – Dramatiskt minskad e-post, Skype- och slackkommunikation
• – Medarbetarna vet vad de ska göra och väljer enkelt sina uppgifter i ett visst projekt
• – Ledningen har en bättre översikt över pågående projekt och vet vad deras team arbetar med
• – Kanban-boards används för att visa upp aktuell projektstatus för kunderna
• – Flaskhalsar identifieras snabbt och kan hanteras
• – Antalet pågående problem har minskat, ledtiderna reduceras följaktligen också
• – Eftersom alla problem är kopplade till GitHub-grenar är det mycket lättare att spåra (och återställa, om det behövs) införda ändringar

Genomförande

Vi har delat upp Kanban-board i 2 huvudsakliga sektioner – den första är intern (analys, utveckling och testning) och den andra är extern (UAT). Vi använder Kanban-board för att spåra ärenden som godkänts av kunden och releasar bara ut dem, medan resten får gå tillbaka till utveckling.

På skärmdumpen nedan kan du se kolumnerna som hör till vår Kanban-board.

Backlog

Det första steget är alltid att skapa ett nytt ärende i backlog. Detta kan göras av en utvecklare, projektledare eller en testare. Det är dock bara projektledaren som ska kunna flytta ärenden till input queue, där de plockas upp av en utvecklare för vidare arbete.

Input queue

Utvecklare väljer i allmänhet ärenden utifrån tidigare erfarenheter av det som behöver lösas (om de har arbetat med liknande frågor) eller vad de tycker kommer att gynna kunden mest. Andra kriterier är självklart hur intressant ärendena ser ut att vara :).

Under utveckling

När ett ärende har plockats flyttas det till kolumnen ‘In development’ där kommer det att stanna tills utvecklingen anses vara färdig. Sedan flyttas den till testkolumnen. Vi strävar efter att ha högst cirka 1,5 ärenden per utvecklare i den här kolumnen.

Analys

Om ett problem kräver extern information från projektledare/kund eller kräver ytterligare forskning eller till exempel skjutas på så flyttas den till “Analys” kolumnen. Där kommer den att stanna tills den är klar för utveckling igen. Att ha för många ärenden i kolumnen Analys är en signal till projektledaren att de borde ge mer detaljer till utvecklarna för att driva projektet framåt.

Test-kö

Ärenden från test-kön plockas upp av testteamet. Om utvecklarna är skyldiga att utföra testning är det viktigt att de inte väljer sina egna ärenden och testar – det är alltid bra att få en second opinion på arbetet.

Testning

Vissa ärenden kan kräva mer omfattande testning och kommer därför att ligga kvar i kolumnen ”Testing” tills det är klart.

Testad

Objekt i den testade kolumnen har genomfört intern utveckling och är redo att releasas för ett slutligt godkännande av användaren (UAT).

UAT

Står för User Acceptance Tests. Här mixar vi Kanban-board för utveckling och affärsändamål. Denna kolumn kan visas för våra kunder under projektmöten där vi diskuterar enskilda frågor och får feedback. Godkända ärenden flyttas till färdiga medan avvisade går tillbaka till backlog eller input queue.

Klart

Ärenden i denna kolumn är accepterade av kunden och redo att releasas. Förflyttningen mellan kolumner är begränsad – det är generellt sätt endast tillåtet att flytta ärenden framåt. Ärenden kan komma tillbaka till backlog men endast vid specifika lägen. Det är inte meningen att ärenden ska kunna flyttas fritt på boarden då det skulle skapa en del oreda i flödet.

Slutsats

Introduktionen av Kanban-boards i vårt arbete hade en dramatisk (utan att överdriva) effekt på projektstyrning och effektivitet. Även de mest grundläggande funktionerna hade positiva effekter på arbetsmoralen och bidrog till att förekomma ett kaos.

Om du väljer att implementera Kanban-metoden så är det viktigt att försöka anpassa det så långt det går till era organisatoriska krav.

Dessutom är benchmarking viktigt (särskilt i början). Granska genomförandet i några veckor för att säkerställa att det verkligen fungerar som ni tänkt.

Framtida arbete

Visst finns det några saker som vi planerar att introducera i vårt arbetsflöde inom en snar framtid för att ytterligare förbättra effektiviteten:

• – expedite items (vi använder dem sällan)
• – swim lanes
• – WIP limits (nu har vi bara mjuka limits)

/ Radek, Technical Director på Visionmate