Att införa nya sätt att arbeta i ett team eller på en arbetsplats, ska det behöva vara så svårt? Och kan jag verkligen bli mer produktiv med hjälp av en Kanban? Svaret är, som alltid, i korthet: ”Det beror på!
Självklart arbetar du inte automatiskt agilt och användarfokuserat bara för att du börjar använda en Kanbantavla. Men rätt använd är en Kanban ett verktyg som kan hjälpa ditt team att förbättra sina resultat och sin produktivitet – och ge stöd när ni vill införa nytt tänkande i en trög och hierariskt uppbyggd organisation som behöver förnyas för att hänga med i utvecklingen.
Grundläggande för det agila eller flexibla mindset som alla gärna pratar om, men kanske inte alltid vet vad det innebär för organisationen och användarna av våra slutprodukter, är att det är demokratiskt. Det 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 samarbeta och på riktigt involvera hela teamet i arbetet, från planering till genomförande. Det ä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 att vara öppen för att vi kan behöva ändra både planering och målsättning och hitta nya lösningar under arbetets gång för att en produkt ska bli riktigt bra, användbar och användarvänlig.
Med den äldre sortens projekttänkande i ”vattenfallsmodell” är det viktigaste oftast att hålla tidsplan och budget. Fokus ligger inte på hur exakt vi tar oss från start till mål, eller på ett gemensamt, flexibelt arbete med utveckling, förändring och innovation.
Bland de fördelar som utlovas med att byta ut “vattenfall” mot ett ”agilt mindset” och ”lean business”, är nöjdare kunder, bättre produkter, högre produktivitet, snabbare och bättre 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”, ”Lean Enterprise” och “SAFe“? Alla bygger på idén om att arbeta mer agilt och närmare affären.
Idealet de flesta organisationer strävar efter är att ha en välstrukturerad, överblickbar och tydlig planering för det gemensamma arbetet. Målet är att frigöra energi och kreativitet, så att arbetsgruppen kan ägna sig åt produktion och innovation och mindre åt administration.
Regelbundna möten och olika sorters planeringsverktyg, analoga eller digitaliserade, är kända metoder och en Kanban är väl trots allt bara en anslagstavla. Så, vad är det då som skiljer den från andra verktyg? Kan den inte till och med användas på “fel” sätt?
Jo, men det beror på!
Eftersom alla nya metoder, system och tankesätt har både en inlärningskurva och en viss missnöjeskvot som måste hanteras gemensamt, blir nästa steg, efter att ha startat en Kanbantavla, oftast att ta itu med förändringar och justeringar. Även om alla i ett team varit involverade i förberedelserna är det omöjligt att förutse allt som kan hända när tavlan väl har börjat spegla vår design och vår produktion. Vi återkommer till detta strax. Först ska vi bara gå igenom lite mer grundligt vad en Kanban är för något och försöka reda ut hur den kan ha potential att underlätta och demokratisera vårt dagliga arbete och hjälpa oss att bli mer agila.
Kanban är från början namnet på en tavla enligt gammal japansk modell. Hos oss har den fått formen av en anslagstavla – digital eller fysisk – med kolumner och signalskyltar, där planering och arbetsprocess kan visualiseras med målet att förbättra. Antingen använder vi en elektronisk Kanban med notiser (Trello, Kanbanflow, Swiftkanban, Workstreams, mfl appar), eller en manuell tavla – där arbetsuppgifterna skrivs ner på post-its som sparas och flyttas framåt i takt med att arbetet fortskrider.
Den här visuella metoden – att visualisera och synliggöra arbetet genom att förvandla delar av det till skyltar som placeras på en tidslinje – 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 börjar använda ett nytt verktyg måste vi vara överens om vad som ska utföras med hjälp av det. 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? När kan vi betrakta en uppgift som slutförd? Och så vidare. Detta måste vi ta tid på oss att fundera över tillsammans, innan vi kan bestämma hur just vårt teams visualisering ska se ut.
Ett sätt är att strukturera är att ha dagliga möten för det mindre teamet – så kallade Daily Scrums där vi kort redovisar för varandra hur arbetet fungerar – samtidigt som vi tillsammans med andra team samarbetar i en större tidsbegränsad så kallad Sprint, med bestämda mål. Varje moment i sprinten kan ha sin egen ”timebox” och arbetsprocessen kan pågå 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. Målen sätts gemensamt och den eller de i strukturen som har ansvar för produktionen, det kan exempelvis vara en Scrum master eller Product owner (beroende på vilken modell som tillämpas) ser till att arbetet går i rätt riktning.
Vi ska göra det enkelt här och bara prata grundläggande om hur en Kanban kan sättas upp och underlätta i vårt utvecklingsarbete. Men för den som vill fördjupa sig i olika agila metoder har vi några rekommendationer.
Ett oerhört populärt sätt att arbeta med design och prototyper, som fortfarande används som modell för workshops på allt från en vecka till bara en, eller några dagar, är metoden Design Sprint. Hur den kan faciliteras beskrevs först 2010 av Jake Knapp, tillsammans med John Zeratsky och Braden Kowitz. Metoden har vidareutvecklats av AJ&Smart och många har skrivit om den, exempelvis Design Foundation IxDF.
Inom ramverket SAFe kallar man sprinten eller timeboxarna från Scrum för Agile Release Train, ART och använder fler modeller för iterationer (vidareutveckling) av produkterna, samt en egen modell för Kanbantavlor.
När vi använder en Kanbantavla är det viktigt att begränsa antalet uppgifter i produktion på tavlan och att inte ha en alltför stor ”backlog”. En oändlig lista med saker som måste göras kan stressa teamet och göra arbetet mindre agilt och innovativt. Oavsett vilket ramverk vi har valt att arbeta med.
Stress är alltid kontraproduktivt eftersom ett stressat team riskerar att börja arbeta efter projektprincipen ”bli klar i tid” snarare än att ”utveckla den bästa, mest användbara och mest användarvänliga produkten”.
När vi har bestämt vilken process vi vill förbättra genom att visualisera och analysera den på en Kanban 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.
Antalet spalter eller kolumner kan förstås vara många fler än tre 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.
Vad som egentligen menas med “Klart” är något som arbetsgruppen också behöver vara överens om. Det innebär att enas om en så kallad ”Definition of Done” där det gemensamt bestäms vad som måste vara gjort innan en uppgift får placeras i fältet ”Klart”.
Det är också klokt att införa en begränsning av antalet uppgifter som får befinna sig i fältet ”Under arbete” (eller WIP, work in progress). Ett riktmärke för antalet uppgifter som kan vara på gång samtidigt kan vara högst tre, per person.
Nu kommer vi till själva lapparna, eller skyltarna. Varje större uppdrag brukar kunna brytas ner till flera deluppgifter, som behöver genomföras. 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 skylt, 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 skyltar eller 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.
Ett enkelt sätt att beskriva hur det här fungerar är att bryta ner uppgiften “borsta tänderna” i mindre steg. Den börjar med att vi går in i badrummet. Nästa steg är att ta fram tandborsten. Tredje steget är att ta fram tandkrämen. Fjärde att lägga kräm på borsten. Femte att faktiskt börja borsta. Och så vidare fram till avslutad borstning där allt ligger på sin plats igen och vi har klivit ut ut badrummet.
Det låter väl enkelt? Eller?
Även här blir svaret: ”Det beror på!”
Hur pass 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. Saknas stöd från ledningen kan det bli svårt att arbeta agilt.
De personer som sitter på en viss andel makt inom en äldre hierarkisk struktur – makt som de riskerar att förlora genom ett nytt och mer demokratiskt arbetssätt – kan utgöra ett stort och trögt hinder för att gruppen ska kunna arbeta agilt. Samtidigt kan de 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 de blir synliga. När det händer och det tar tvärstopp, kan vår Kanban (och arbetsgrupp) 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 försöka arbeta agilt och införa en Kanban måste ges upp. Men då, mitt under pågående Kanbankris, dök det upp något online i flödet av information som gav mig precis den aha-upplevelse jag behövde för att hitta lösningen på mitt och teamets Kanbanproblem.
– Först en flashback. Under en kurs jag gick 2018 hos Informator för att bli Scrum Master hade jag turen att ha inspirerande pedagog som lärare: 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 hittade jag både hans föredrag och blogginlägg om konsten att sköta en Kanban på webben. Jag kan verkligen rekommendera er som är specialintresserade av detta ämne att följa Christophe på tex LinkedIn. Och att även följa bloggen hos det agila konsultföretaget Crisp där han är en av medarbetarna –
Christophe Achouiantz 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 behövde teamet förstå orsakerna bakom krisen och hur den påverkade vårt arbete. Kanbankrisen gav oss därmed en möjlighet att identifiera flera grundläggande problem inom organisationen som låg i vägen för oss. Så länge de här problemen var olösta och framför allt inte adresserade, var det omöjligt att arbeta agilt. Jag ska förklara mer i detalj.
Initialt brukar en Kanban så gott som alltid förbättra ett teams arbete. Men efter den första smekmånaden hamnar de flesta i en svacka. Det kan yttra sig på flera sätt och vara mer eller mindre allvarligt. 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 kan se 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, börjar den nämligen 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åra hypoteser om arbetet 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.
Målen på en Kanban måste hela tiden justeras för att reflektera hur arbetet fungerar i praktiken, 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 med all produktutveckling. Tavlan 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 efter åtgärd 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 bara 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 om ett strukturellt problem i organisationen, där det länge hade pågått ett tyst uppror mot ett alltför auktoritärt ledarskap. För att kunna bestämma själva hur de skulle arbeta och inte behöva redovisa vad de åstadkommit sedan sist hade medarbetarna byggt upp metoder och vanor för att ”gömma sig”, eller ”smita undan”. Bara de höll sina slutliga deadlines, så kunde ingen säga något. Så fungerade det gamla hierarkiska systemet, som ingen ville ha.
Lösningen blev att bromsa visionen och ta “babysteps”, låta medarbetarna i teamet själva bestämma hur snabbt de ville börja arbeta mer agilt, med insikten om att de själva kunde bestämma hur de skulle arbeta. Samtidigt sökte jag stöd hos ledningen för arbetsmetoden och fick det.
Lösningen blev att först dela ut färre och mer specificerade uppgifter, som kunde följas via teamets Kanban. Stegvis gav det alla i teamet möjlighet 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 och följ dem på Linkedin för tips och material. Vi bifogar några länkar här under.
Text: Aminata Grut
Foto: Airfocus/Unsplash, Wonderlane/Unsplash, Ian Keefe/Unsplash.
Smidigt. En minikurs online om agilt arbete, av coachen 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, Lean/Agile Transformation Coach, 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).
Rachel McConnel, Senior Design Manager på OVO, skriver på Medium om “How to foster effective teamwork and smash your product objectives“.