Att införa nya arbetsverktyg, ska det behöva vara så svårt? Och kan jag verkligen bli mer agil med hjälp av en Kanban? Svaret är, i korthet: ”Det beror på!
Självklart arbetar du inte automatiskt agilt bara för att du börjar använda en Kanbantavla. Men rätt använd kan en Kanban hjälpa till att införa ett nytt tänkande i en hierarisk och trög organisation som behöver förnyas – och hjälpa ditt team att förbättra sina resultat och sin produktivitet.
Bland de fördelar som utlovas med att byta ut projekttänkande i ”vattenfallsmodell” mot ett ”agilt mindset” och ”lean” business, är nöjdare kunder, högre produktivitet, snabbare leverans och gladare medarbetare. Inte bara industrin utan också många andra verksamheter vill hänga på i utvecklingen. Kanske har du hört talas om ramverket Scrum, där Scrum Masters, Product Owners och Development Teams arbetar med snabb produktutveckling, eller senare tillkomna agila affärsmodeller som ”Lean Startup” och ”Lean Enterprise”?
Grundläggande för det agila eller flexibla mindset som är så eftertraktat är att det involverar hela teamet, hjälper oss att snabbt kunna ändra riktning tillsammans och uppnå bättre resultat än förväntat, ofta på ett annat sätt än vi från början tänkt oss.
Att vara agil är att vara beredd på förändring, vara medveten om att vi inte alltid vet vad vi behöver göra för att nå uppsatta mål och vara öppen för att vi kan behöva ändra både planering och målsättning under arbetets gång. Det är också att involvera hela teamet i arbetet med planering och genomförande. I den äldre sortens projekttänkande med en mer trög och hierarkiskt uppbyggd organisation, är det viktigaste oftast att hålla tidsplan och budget. Det finns inte på samma sätt utrymme för ett gemensamt, flexibelt arbete med utveckling, förändring och innovation.
I de flesta verksamheter finns ett behov att på något sätt strukturera det gemensamma arbetet. Det vanligaste är att ha regelbundna möten eller att använda olika sorters planeringsverktyg, analoga eller digitaliserade. Idealet är att ha en välstrukturerad, tydlig och överblickbar planering, som frigör energi och kreativitet så att arbetsgruppen kan ägna sig åt produktion och innovation och mindre åt administration. Så långt är det inget som skiljer en Kanban från andra verktyg.
Alla nya system och tankesätt har förstås både en inlärningskurva och en viss missnöjeskvot som måste hanteras gemensamt. Även om alla i ett team varit involverade i förberedelserna, för att starta arbetet med exempelvis en Kanbantavla, blir nästa steg efter införandet oftast att ta itu med förändringar och justeringar. Vi återkommer till detta strax. Först ska vi bara gå igenom vad en Kanban är för något, hur den kan hjälpa oss att bli mer agila, underlätta och demokratisera vårt dagliga arbete.
En Kanban är en tavla enligt gammal japansk modell, med kolumner och signalskyltar, där planering och arbetsprocess visualiseras. Antingen använder vi en elektronisk Kanban med notiser (Trello, Kanbanflow, Swiftkanban, Workstreams, mfl appar), eller en manuell tavla där uppgifterna skrivs ner på post-its som sparas och flyttas framåt i takt med att arbetet fortskrider. Den visuella metoden gör att inget kan genomföras eller lämnas åt sitt öde en längre tid utan att vi får syn på det. Vårt arbete blir därmed också mer demokratiskt och transparent, eftersom vår Kanban tvingar oss till öppenhet och ärlighet i diskussionerna kring hur vi ska hitta lösningar.
Innan vi skissar upp strukturen för tavlan, måste vi ta itu med att specificera de uppgifter som ska utföras, det vill säga: bestämma vad vi ska ha tavlan till. Vi behöver alltså börja med att gemensamt diskutera det övergripande målet med vårt arbete. Varför gör vi det här? Vilket eller vilka mål vi vill uppnå? I vilken ordning ska saker göras? Vilka är våra argument för det? Vilka ska vara inblandade? Osv. Allt detta måste vi ta ett antal timmar på oss att fundera över tillsammans. Ett bra sätt är att strukturera arbetet i en tidsbegränsad så kallad ”sprint”, där varje moment har sin egen väl beprövade ”timebox” och där hela processen pågår i minst en vecka, högst en månad, för att sedan utvärderas och följas av en ny sprint om det behövs.
Det är viktigt att begränsa antalet uppgifter i produktion på tavlan och att inte ha en alltför stor ”backlog”, dvs en oändlig lista med saker som måste göras, eftersom det kan göra det utvalda teamets arbete mindre agilt. Om arbetsgruppen är stressad blir det lätt kontraproduktivt eftersom alla riskerar att börja arbeta efter projektprincipen ”bli klar i tid” snarare än att ”utveckla den bästa produkten”.
Först ska vi alltså bestämma hur vi ska använda vår Kanban, det vill säga vilken process vi vill förbättra, genom att visualisera och analysera den. När vi har bestämt detta ska teamet också avgöra hur många kolumner, eller spalter, vår Kanban behöver ha. Tre eller fyra brukar vara ett minimum.
I grundutförandet med fyra spalter hamnar lappar med noteringar om allt som vi vet behöver göras i den första spalten, som vi exempelvis kan döpa till ”Att göra”. Nästa spalt kan vara till för uppgifter som ska delas ut för åtgärd och heta tex ”Prioriterade”. Sedan kommer spalten ”Under arbete” och sist ”Klart”. Kanske vi också behöver en extra kolumn som vi döper till ”Blockerat”, för uppgifter som inte kan utföras förrän något annat har blivit klart.
Arbetsgruppen måste vara överens om vad som egentligen menas med ”Klart”, det vill säga alla måste enas om en så kallad ”Definition of Done” där det gemensamt bestäms vad som måste vara gjort innan lappen får placeras i fältet ”Klart”. Det är också klokt att införa en begränsning av antalet lappar som får befinna sig i fältet ”under arbete” (eller WIP, work in progress).
Antalet spalter eller kolumner kan förstås vara många fler beroende på hur komplext det arbete vi ska utföra är. Beroende på vilken bransch vi arbetar i kan teamet döpa de olika kolumnerna, eller spalterna, efter de olika stadier en produkt eller uppgift måste passera innan den kan betraktas som utförd, eller ”Done”. Kanske det exempelvis behövs extra kolumner för ”Testas”, ”Ska godkännas” osv.
Nu kommer vi till lapparna. Varje större uppdrag brukar kunna brytas ner till flera deluppgifter. Deluppgifterna skrivs ner på var sin digital skylt eller post-it som får sitta kvar på Kanbantavlan hela vägen fram till ”Done” för att alla ska kunna ha överblick. I de elektroniska kanbantavlorna kan vi lägga till information inuti varje ”lapp”, exempelvis länkar eller bara noteringar om sådant som är bra för andra medarbetare att känna till.
De olika deluppgifterna fördelas mellan olika teammedlemmar, men alla tar gemensamt ansvar för att de slutförs och för att övervinna hinder och problem i arbetet. När en uppgift är slutförd hamnar våra post-its slutligen i kolumnen ”Klart” och vi kan ta på oss nya uppdrag från vår backlog, tills vår sprints timebox är slut.
Det låter väl enkelt? Eller?
Även här blir svaret: ”Det beror på!”
Hur enkelt det här blir beror inte bara på hur gruppens medlemmar ställer sig till förändringar och nymodigheter, hur involverade de varit i processen med att införa Kanban i arbetet och hur deras personliga ”mindset” ser ut. Det beror också på hur verksamhetens ledning ser på ert arbete. De personer som sitter på en viss andel makt inom en äldre hierarkisk struktur – makt som de känner att de riskerar att förlora genom ett nytt arbetssätt – kan utgöra ett stort och trögt hinder för att gruppen ska kunna arbeta agilt. På samma sätt kan medarbetare som inom en hierarkiskt strukturerad organisation betraktats som ”besvärliga”, ”motvalls” eller ”bråkiga”, ha lättare att ta till sig ett snabbt, rörligt, agilt arbetssätt där det är öppet för idéer och förslag till förändring och bestämmandet över processerna är jämnare fördelad.
En Kanban, använd på rätt sätt, ger oanade möjligheter att få syn på svagheter och styrkor i en organisations struktur. Framför allt avslöjar den vad som INTE fungerar. Det vill säga de hinder som fortfarande ligger i vägen för utveckling (och snabbare produktion) kommer relativt snart att uppenbaras. När det händer och det tar tvärstopp, kan vår Kanban hamna i en djup kris.
Ett exempel. Efter att under ett uppdrag ha ”kört in i väggen” med en arbetsgrupp – och en Kanban som det verkade helt hopplöst att få fungerande igen – började jag i desperation gå igenom tidigare arbetsmaterial för att hitta svar på vad som gått fel. Det verkade ett tag som om hela projektet att införa en Kanban och försöka arbeta agilt måste ges upp. Men då, mitt under pågående Kanban-kris, dök det upp något i flödet som gav mig precis den aha-upplevelse jag behövde för att hitta lösningen på mitt och teamets Kanbanproblem.
Svaret kom i ett blogginlägg. Den kurs jag gick för att bli diplomerad Scrum Master hos Informator leddes av Christophe Achouiantz, erfaren agil och diplomerad coach och föreläsare som kan Scrum, Lean, DevOps, Kanban och som just då var Agil Coach för ett stort antal scrum masters och deras tekniska team på Telenor. Han bjöd generöst oss elever på insiktsfull och lekfull undervisning och efter kursen förstod jag att det även fanns möjlighet att fortsätta följa hans blogg och lyssna på föredrag via webben. Jag kan verkligen rekommendera er som är specialintresserade av detta ämne att följa honom på tex LinkedIn. Och att även följa bloggen hos det agila konsultföretaget Crisp där han är en av medarbetarna.
Christophes inlägg ”How to get your Kanban back on track” hjälpte mig hitta lösningen på den Kanbankris min arbetsgrupp hamnat i. Framför allt insåg jag att vi kunde hitta lösningen om vi förstod oss på själva krisen och orsakerna till den. Kanbankrisen gav oss alltså en möjlighet att lösa grundläggande problem som låg i vägen för arbetet.
Initialt brukar en Kanban så gott som alltid förbättra teamets arbete. Men efter den första smekmånaden hamnar alla i en svacka. Det kan yttra sig på flera sätt. Det kanske finns för många lappar på tavlan, den speglar inte arbetet i realtid, mötena är för långa osv. Och det ser ut att finnas en allvarlig mismatch mellan hur teamet tror att de arbetar och hur de verkligen arbetar.
Precis som vår Kanban vid starten speglar en vision för hur arbetet ska kunna genomföras, kommer den också snart att börja visa oss om visionen är för långt från verkligheten. Om vi tex förutsätter att teamet ska kunna arbeta mer avancerat än alla är mogna för, utan att vara mottagliga för att vår hypotes kanske inte stämmer, så slutar systemet snart att fungera. Gapet mellan verklighet och vision gör att medarbetarna överger både visionen och Kanbantavlan. För att detta problem inte ska uppstå måste målen på en Kanban hela tiden justeras – för att kunna reflektera hur arbetet fungerar, vilka hinder som uppstår och vilka resultat som uppnåtts. När vi utvecklar ett Kanbansystem måste vi alltså göra på ungefär samma sätt som vid all annan produktutveckling. Den måste anpassas till teamet och till arbetsflödet och ses som en metod för att upptäcka problem och få möjlighet att göra något åt dem, för att kunna nå bästa möjliga resultat.
I det aktuella fallet var det stora hindret att teammedlemmarna inte hade varit tillräckligt transparenta tidigare, med varandra, kring hur de arbetade. De kände sig inte trygga nog att föra en öppen diskussion och upplevde att kraven på dem från chefsnivå var för höga.
När tavlan riskerade att bli för avslöjande blev redovisningarna luddigare och ingen förstod vad som stod på tavlan eller vad som egentligen hade gjorts sedan förra mötet. Att-göra-listan blev längre och längre och missnöjet större och större med att arbetet inte gjort tillräckliga framsteg. Teamet började ifrågasätta nyttan med att ha en Kanban och om den verkligen kunde hjälpa dem att åstadkomma bättre resultat i verksamheten. Men egentligen handlade det alltså om ett strukturellt problem, i en organisation där medarbetarna sedan tidigare kände ett behov av att ”gömma sig”, ”smita undan”, eller bestämma själva hur de skulle arbeta och inte behöva redovisa vad de åstadkommit sedan sist bara de höll sina slutliga deadlines.
Lösningen blev att bromsa visionen, göra den mindre ambitiös, låta medarbetarna själva bestämma att ta på sig färre och mer specificerade uppgifter via teamets Kanban. Stegvis kunde vi få alla i teamet att inte bara acceptera men också börja uppskatta arbetssättet, öppenheten och det stöd det är möjligt att både ge och få genom att arbeta agilt, transparent och med större inflytande för alla medarbetare. Resultatet i just det här fallet blev till slut bra.
Vill ni veta mer om agilt arbete, agila verktyg och agilt mindset? Hör av er!
Läs som sagt också vad erfarna agila coacher skriver. Vi bifogar några länkar.
Smidigt. En blogg om agilt arbete, av Ola Berg. ”Ett av fundamenten i de agila metoderna är att de som arbetar i processen också äger processen. Varför? För att den som är närmast värdeskapandet ofta bäst förstår hur det ska göras.”
”How to Get your Kanban Initiative Back on Track!” Inspelning av ett webinar med Christophe Achouiantz, om ”policy-gap-fällan som kan orsaka tvärstopp i en Kanban och hur resultatet kan bli – en vinst!” (föreläsningen startar vid 09:35).
