Hvad er Kanban? Få en introduktion til Kanban!

I dette indlæg skal vi kigge lidt på Kanban, en ofte overset projektledelsesmetode, men som faktisk er min go-to metode at drive projekter med. 

Grunden til dette vil være indlysende for dig efter at have læst dette indlæg, men kort fortalt, så er Kanban mindre omfattende end mange andre metoder, såsom Scrum eller Prince2. Med det mener jeg, at du som projektleder kan bruge mere tid på projektet, og mindre tid på papirarbejde og mødeindkaldelser. 

Igennem indlægget her har jeg inkluderet nogle videoer fra Atlassian. Prøv at give dem et kig, de er godt lavede og forklarer på en underholdende måde, hvad Kanban er for en størrelse. 

Kanban kræver ikke en komplet nytænkning af den måde, I arbejder på i din virksomhed i dag. Den kan nemt tilpasses alle jeres eksisterende processer og rammer. 

Dette er et stort plus i forhold til Scrum, hvor der er mange processer, som skal laves om for at udnytte det fulde potentiale af Scrum. 

Kanban er i dag enormt populært blandt agile software teams, men Kanban-metodikken er faktisk mere end 70 år gammel. 

I slutningen af​​ 1940erne begyndte Toyota at optimere deres produktions processer, baseret på den samme model, som supermarkederne tidligere brugte til at sikre, at der altid var varer på deres hylder. 

Supermarkeder lagrer nemlig kun lige nok produkter til at imødekomme forbrugernes efterspørgsel, en praksis, der optimerer supermarkedets processer og indkøbs flow. 

Da Toyota anvendte det samme system på sine fabriksgulve, var målet at justere deres relativt høje lagerniveauer bedre med det faktiske materialeforbrug. 

For at kommunikere kapacitetsniveauer i realtid på fabriksgulvet (og til leverandører), skulle fabriksmedarbejderne sende et kort, eller “Kanban”, mellem afdelinger i virksomheden. 

Når en beholder med materialer, der blev brugt på produktionslinjen, blev tømt, blev et Kanban‐kort sendt til lageret, der beskrev, hvilket materiale der var behov for og den nøjagtige mængde af dette materiale osv. 

Lageret ville så sende en ny beholder med dette materiale og den præcise mængde til fabriksgulvet. 

Derefter ville de sende det samme Kanban kort til deres leverandør. Leverandøren ville derefter også gøre en beholder med netop dette materiale klar, og sende den til lageret, så der hele tiden var en konstant mængde på lager. 

Selvom teknologien har ændret sig siden 1940erne, og man ikke længere bruger fysiske Kanban kort, så benyttes denne “just in time” (eller JIT) fremstillingsproces stadig i Toyota.

Kanban som metode til agile projekter

Jeg arbejder primært med digitale projekter, som lanceringer af webshops, mobil apps, hjemmesider og andre digitale løsninger. 

Jeg har drevet mine projekter efter flere forskellige projektledelsesmetoder, herunder både Prince2, Scrum, Extreme Programming og selvfølgelig Kanban. Min klare anbefaling for folk, der ikke er certificerede inden for Prince2 eller Scrum, er helt sikkert at bruge Kanban. 

Kanban kan hjælpe dig til at benytte dig af den samme “Just-in-time” metode, som Toyota brugte, for at sikre at du bruger dine egne og kollegers ressourcer bedst muligt. 

Men lad os dykke lidt ned i, hvad Kanban egentlig er, og hvad det består af. Så nedenfor kan du læse lidt mere om Kanban boards, cards og WIP limits. De tre grundsten for Kanban, som en projektledelsesmetode. 

Kanban Boards

Et board er en slags opslagsvæg, på billedet ovenfor er det alt det blå. Det fungerer i praksis som rammen for dit projekt, derfor vil du som udgangspunkt oprette et board for hvert projekt, du skal i gang med.

Et board i sig selv giver dig ikke meget værdi, det er først når du laver kolonner og cards, at du begynder at se værdien af et Kanban board.

Et Kanban board er et projektstyringsværktøj, som der er designet til at hjælpe dig med at visualisere arbejdet i projektet. Det er også med til at maksimere effektiviteten (eller flowet) af projektets fremgang. 

Kanban boards består af kort, kolonner og kontinuerlig levering for at hjælpe dig og projektgruppen med at få ført projektet ud i livet. 

Mens fysiske boards og post-its er populære blandt nogle projektledere, så synes jeg, at digitale boards er langt nemmere at arbejde med i ethvert agilt projekt. Både fordi det er lettere at samarbejde, og fordi det er tilgængeligt, uanset hvor du befinder dig.

Et grundlæggende Kanban board har en arbejdsgang i fem trin: Idea, Start, Doing, Pending og Done. Afhængig af et holds størrelse, struktur og mål kan arbejdsgangen imidlertid laves om for at imødekomme den unikke proces for en bestemt projektgruppe eller projekt.

Til mine hverdagsopgaver bruger jeg selv Kanban til at sortere alle mine opgaver efter, og bruger fem kolonner til at styre dem: “Idea”, “Start”, “Doing”, “Pending” og “Done”. Ideen bag denne opdeling er som følger:

• Idea: Når du får en god ide opretter du opgaven i “Idea”, så kan du på dit næste teammøde præsentere ideen for dine kollegaer, hvor de andre kan være med til at vurdere, om det vil give værdi for virksomheden. 
• Start: Hvis din ide bliver godkendt, kan du trykke den over i “Start”, hvor den vil vente, indtil I har ressourcer til at kigge på den. 
• Doing: Når I har fået noget fra hånden, og “Doing” kolonnen er ved at være tom, så kan man vælge, hvilke kort der fra “Start” skal rykkes til “Doing”, som så bliver de opgaver, man skal kigge på den kommende tid. 
• Pending: En opgave rykkes til pending, når opgaven er færdig, og skal godkendes af en stakeholder, eller opgaven er stoppet midlertidigt grundet manglende input fra en stakeholder (internt eller eksternt) eller manglende ressourcer (penge, værktøjer, tid). Derefter rykkes den tilbage til “Doing”, hvis du stadig skal arbejde på den, efter du har fået de givne ressourcer.
• Done: Når en opgave er helt færdig, og den er blevet godkendt, kan man derefter trække den over i “Done”.

Der er ikke nogen begrænsning for hvor mange kolonner du kan have.

Kanban Cards

Et card er en opgave, som du kan oprette i en List, på billedet ovenfor er det de hvide bokse i listen. Så du opretter et card for hver opgave i dit projekt, og beriger det, med alle de informationer som der skal til for at løse opgaven.

Kanban-kortet er en væsentlig komponent i Kanban. Hvert Kanban-kort repræsenterer en enkelt delopgave, hvor du kan skrive omkring opgaven, og følge den, når den bevæger sig gennem de forskellige stadier eller kolonner på Kanban boardet. 

For at få en idé om, hvad et Kanban-kort er, kan du forestille dig et softwareudviklingsprojekt, hvor der bruges sticky notes på en tavle til at repræsentere deres delopgaver i projektet. 

Når de arbejder nye funktioner, bevæger delopgaverne sig for eksempel gennem kolonner mærket Idé, Design, Udvikling, Testning, Blokeret og Udført.

Når designerne f.eks. nar tid til at kigge på en delopgave så trækker de et Kanban-kort fra Idé til Design kolonnen, og når så udvikleren er klar til endnu en delopgave, vil en udvikler trække et færdigt kort fra kolonnen Design til Udvikling. 

Kanban-kort sporer udviklingen af en delopgave gennem disse faser, så teamet altid kender historien og status for hver delopgave til enhver tid.

Kanban-kort indeholder kritiske oplysninger om den pågældende delopgave, hvilket giver hele projektgruppen fuldstændig synlighed af, hvem der er ansvarlig for den pågældende delopgave, en kort beskrivelse af det der laves, hvor lang tid det forventes at tage, og så videre.

Herunder er der et eksempel på et Kanban card, der kan du se at de har udfyldt titlen, beskrivelsen og lavet en tjekliste:

Der er ikke nogen grænse for hvor mange tjeklister, personer eller dokumenter, som du kan have på et card. Nogle opgaver har bare en titel, en kort beskrivelse og en person tilknyttet kortet. Men andre opgaver kan være meget uddybende. Jeg har haft et card med over 100 punkter på en tjekliste og med en utrolig lang kommentar diskussion med de andre i projektet, og med mere end 10 vedhæftede Excel-ark. 

Work-in-progress (WIP) limits

Work-in-progress er en grænse, man kan stille for, hvor meget arbejde man kan have i en given kolonne til enhver tid. 

At begrænse mængden af igangværende arbejde gør det lettere at identificere ineffektivitet i en projektgruppes arbejdsgang. Flaskehalse i en projektgruppes leverancer bliver gjort langt mere synlige, når der ikke er så mange igangværende opgaver i hver kolonne. 

Man smider derfor et maks antal delopgaver/kort i hver kolonne, hver kolonne bør ikke nødvendigvis have et maks antal, for eksempel “Done” kolonnen behøver det ikke, da der typisk ikke er mere arbejde på de kort, der ligger i den kolonne. 

Under projektet kan man let komme til at tænke “Åh, jeg sætter lige denne delopgave på pause, mens jeg begynder at arbejde på en anden.” 

At have mange opgaver igang betyder, at personen nu skal skifte mellem de mange forskellige opgaver og ikke kan nå at koncentrere sig om de vigtigste mål ved hver opgave. 

Som med enhver ny aktivitet kan WIP-grænser føles akavede i starten. Målet her er at optimere projektgruppen på mellemlang sigt, og den kortsigtede akavethed er faktisk en god ting. 

Hvis projektgruppen har mødt deres WIP-grænser i et par uger i træk, skal du foretage justeringer efter behov. Enten skal du sikre dig, at den ikke bliver mødt, hvis projektgruppen mener, den nuværende arbejdsbelastning er passende. Men hvis de mener, de sagtens kunne klare flere opgaver, så kan du sagtens justere grænsen op. 

Fordelene ved Kanban

Kanban er gået hen og blevet en af de mest populære agile softwareudviklingsmetoder. Kanban tilbyder nemlig flere fordele ved opgaveplanlægning og organiseringen omkring projektet.

Fleksibilitet af planlægning

En projektgruppe der arbejder efter Kanban er kun fokuseret på den delopgave, der aktivt er i gang. Når teamet er færdig med en delopgave, plukker de den næste delopgave ud fra toppen af backloggen.

Du kan som projektleder frit prioritere opgaverne i backloggen uden at forstyrre projektgruppen, fordi ændringer uden for de aktuelle delopgaver ikke påvirker projektgruppen. 

Så længe du som projektleder holder de vigtigste delopgaver på toppen af backloggen, er udviklingsholdet forsikret om, at de leverer maksimal værdi tilbage til virksomheden.

På den måde behøver du ikke have faste sprints, og du behøver ikke at planlægge alt for meget. Du kan bare blive ved med at prioritere backloggen og lade udviklerne klare opgaverne så hurtigt som muligt.

Færre flaskehalse

Multitasking dræber effektiviteten. Jo flere delopgaver, der arbejdes med på et givet tidspunkt, jo mere spildtid er der, når projektgruppen skal skifte mellem opgaverne. 

Derfor er en af grundprincipperne i Kanban at begrænse mængden af ​​igangværende opgaver (WIP). 

Hvis kolonnen “Igang” for eksempel har mødt dens grænse for opgaver, vil du tydeligt kunne se flaskehalsen, i og med nogle personer i projektgruppen pludselig begynder at have svært ved at følge med.

Et godt eksempel er eksempelvis designere eller QA-managers i digitale projekter. Det er sjældent, at man har for lidt udviklere, men det er desværre for tit, at man sparer på designere og QA-managers i stedet. Så derfor vil disse personer være mere belastende for at kunne følge med.

Hvis der ikke var nogle WIP limits på en given kolonne, så ville alle udviklerne bare smide al koden over i QA (Quality Assurance) kolonnen, og den ene QA-manager vil pludselig hurtigt få en uoverskuelig backlog med opgaver. 

Dette kan gøre det svært at prioritere opgaverne, det bliver omstændigt at arbejde på for mange forskellige opgaver på én gang, og det kan hurtigt blive stressende at prøve at følge med. 

Men ved kun at give en QA-manager 2-3 opgaver at fokusere på, så kan han nemmere springe ind i en opgave, og bare gå i gang, uden at skulle planlægge sin tid alt for meget. 

Kontinuerlig levering

En ting, som mange ikke ved, er at kontinuerlig levering, en praksis hvor man skriver og afprøvning af kode trinvist hele dagen/ugen, faktiske er vigtig for at opretholde kvaliteten af sit arbejde. 

Et at de store problemer med Scrum er, at man alt for sent opdager, at det arbejde man har lavet, ikke lever op til brugerens behov. I Scrum planlægger man ofte sprints 6-8 uger frem, så en større ændring til koden kan først ske 8-10 uger ude i fremtiden. 

Det er alt for langsomt. Se nu en webshop, der omsætter for et trecifret millionbeløb om året, hvis du har en vigtig ændring, som pludselig skal vente i 2-3 måneder, så er det en signifikant del af året, som er gået uden denne vigtige funktion. 

Med Kanban kan du dagligt, eller faktisk hver time, levere ny kode til dine kunder/brugere. Dette er fordi Kanban ikke lancerer koden i sprints, man lancerer i stedet hver ny feature, en efter en, så snart de er udviklet og testet. 

Og jo hurtigere en projektgruppe kan levere nye idéer til markedet, jo mere konkurrencedygtigt, vil jeres produkt/virksomhed være på markedet. Og et Kanban projekt fokuserer på netop dette: optimering af strømmen af leveringen af nye features og rettelser af bugs.

Scrum vs. Kanban

Agil projektledelse er en struktureret og iterativ tilgang til projektstyring og produktudvikling. Agil projektledelse anerkender volatiliteten i produktudviklingen og giver projektgruppen en metode til at reagere på ændringer uden, at projektet går fuldstændigt af skinnerne. 

I dag er agil projektledelse næppe en konkurrencefordel længere. Næsten alle bruger agile principper til at udvikle hjemmesider, apps og så videre.  

Der er ikke mange som har den luksus at kunne udvikle et produkt i mange måneder eller år i en sort kasse, uden at få det verificeret af en bruger undervejs. 

Kanban og Scrum deler nogle af de samme tankegange, men har meget forskellige tilgange til dem. De skal ikke forveksles med hinanden, nedenfor kan du se nogle forskelle imellem dem.

Opsummering

Kanban er pt. en af de projektledelsesmetode, som jeg bruger oftest til mine projekter. Den primære grund til det er, at jeg har erfaret mig, at det er nemmere at introducere i virksomhederne. 

Det er nemmere at have folk med i projektgruppen, som ikke nødvendigvis er vant til at drive projekter, da der nærmest ingen regler er i Kanban, men hvor eksempelvis Scrum næsten kræver et uddannelsesforløb for at deltage i sådan et projekt. 

Men den primære grund til, at jeg foretrækker, Kanban er nok på grund af kontinuerlig levering, altså at det som der udvikles leveres til kunderne eller brugerne næsten med det samme. 

Det betyder at du kan komme på en idé om mandagen, udvikle den tirsdag og onsdag, teste den torsdag og lancere den om fredagen. 

Så man får med andre ord, at en projektledelsesmetode, som er let at implementere i organisationen, det er nemt for projektgruppen at være en del af projektet og arbejde effektivt, og du kan som projektleder hurtigt vise nogle resultater af dit arbejde. Det er i mine øjne en win-win-win situation.