Så skapar du agilitet i projekt (med Dimitar Karaivanov från Kanbanize)

Läs transkriberingen:

Vi testar att transkribera våra poddavsnitt med hjälp av ett program. Ha överseende med eventuella stavfel eftersom roboten inte är korrekt 100 procent av tiden.

Ben Aston:

Lean, Scrum, Scrumban, XP, SAFe, DaD, LeSS, DSDM, Kaizen, Kanban. Känns det bekant? Det här är bara några av de ramverk som finns för att leverera agilt. Men vilket är bäst och varför? Fortsätt lyssna på den här podden för att förstå hur du kan skapa agilitet i dina projekt och vilka fördelar ett Kanban-baserat arbetssätt och verktyg kan ge.

Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager. Välkommen till DPM-podden. Vårt uppdrag är att hjälpa projektledare att lyckas och att hjälpa personer som leder projekt att leverera bättre resultat. Vi vill hjälpa dig att ta ditt projektarbete till nästa nivå. Besök thedigitalprojectmanager.com för att läsa mer om den utbildning och de resurser vi erbjuder genom medlemskap. Den här podden presenteras av Clarizen, ledande inom programvara för företagsövergripande projekt- och portföljhantering. Besök clarizen.com för att läsa mer.

I dag har jag sällskap av Dimitar Karaivanov. Dimitar är ingenjör som blev vd och han är medgrundare av Kanbanize. Han tänker lean, arbetar praktiskt med Kanban och har en bakgrund inom programvaruutveckling och processförbättring. Han har skrivit ett par böcker, Lean Software Development With Kanban och How Can Portfolio Kanban Benefit Your Business? Jag tror att ni förstår bilden. Han brinner för Kanban. Hej Dimitar, tack för att du är med oss i dag.

Dimitar Karaivanov:

Ben, tack för att jag fick komma. Det är trevligt att prata med dig och din publik. Jag ser fram emot den här podden.

Ben Aston:

Ja, det är roligt att ha dig här. Du brinner uppenbarligen verkligen för Kanban och du har byggt en hel produkt kring Kanbanize. Men i din roll som vd är jag nyfiken på vad det faktiskt innebär. Hur ser en vanlig dag ut för dig som vd och medgrundare av Kanbanize?

Dimitar Karaivanov:

Som vd för företaget, särskilt i ett företag som befinner sig i den senare delen av uppstartsfasen, måste man bära många hattar. Jag pratar vanligtvis med många kunder eftersom jag ofta kliver in i rollen som produktansvarig.

Ben Aston:

Just det.

Dimitar Karaivanov:

Sedan pratar jag med ingenjörsteamet för att förmedla den återkoppling vi har fått från kunderna. Jag arbetar med företagsförsäljning. Och naturligtvis ägnar jag mig åt strategi när tiden tillåter, eftersom det är en viktig del av vad vd:ar gör. Strategi kan för övrigt också tillämpas med Kanban. Så vi borde kanske hitta några minuter för att prata om det.

Ben Aston:

Ja, definitivt. Men innan vi går in på det är jag nyfiken på din bakgrund. Hur började du arbeta med att skapa programvara för projektledning?

Dimitar Karaivanov:

Det brukar börja med ett behov. Jag var förändringsledare på ett stort tyskt företag. Vi gick från vattenfallsprocesser till agila processer och överförde ungefär 500 personer från det gamla sättet att driva projekt till Scrum. Scrum var standarden för alla nya agila implementationer. Vi utbildade alla i Scrum. Vi hade ett antal agila team, 25 eller fler, men upptäckte att även om teamen på något sätt kunde leverera stabilt så var det kaos på ledningsnivå, där de större arbetsdelarna fanns – i vårt fall funktioner, epics och liknande. Jag insåg att vi saknade verktyg för att hantera både teamnivån och lednings- och samordningsnivån. Det var så Kanbanize faktiskt föddes, med målet att skala agilitet genom hela organisationen.

Ben Aston:

Okej. När man startar och bygger ett PM-verktyg för första gången måste man ha hämtat inspiration från andra verktyg som man tyckte om, och även från verktyg man inte tyckte om och därför ansåg att man behövde bygga något själv. Var kom den ursprungliga inspirationsgnistan ifrån?

Dimitar Karaivanov:

Vi använde JIRA på det företaget. Det är den stora Godzilla-maskinen på 300 pund som finns överallt. Den innehåller en hel del bra saker. Men Kanban-delen, särskilt för åtta eller nio år sedan, saknades helt eller var mycket begränsad. Många av de bra koncepten kom faktiskt från en fysisk Kanban-tavla och från vår erfarenhet av att skala Kanban och agilitet genom organisationen. Med Kanbanize försökte vi efterlikna hur man visualiserar sitt arbete på en fysisk Kanban-tavla, med det stora tillägget att den är digital och kan kopplas samman med flera andra team samt samla data så att ledningen kan fatta välgrundade beslut. Det är egentligen två verktyg: JIRA och fysiska Kanban-tavlor.

Ben Aston:

Och även om ni har skapat ert eget projektledningsverktyg är jag nyfiken på vilka andra verktyg Kanbanize integreras med, eller vilka ni använder parallellt med Kanbanize för att driva företaget.

Dimitar Karaivanov:

Jag skulle inte vilja vara utan Microsoft Teams, eftersom jag tror att det är den snabbast växande applikationen i internets historia. Det är ett fantastiskt verktyg och vi använder det tillsammans med Kanbanize. Jag tillbringar mycket tid i Teams, särskilt nu när vi alla arbetar på distans. Sedan tillbringar jag förmodligen halva dagen i ett verktyg som heter Flow-e. Det finns på flow-e.com och är, överraskande nog, ett verktyg från vårt företag. Det är Kanbanize för din e-post. Det är ett visualiseringslager ovanpå Outlook-e-post som gör om inkorgen till en Kanban-tavla där du kan visualisera dina e-postmeddelanden och hantera konversationer i en Kanban-liknande vy. Det är en livräddare för mig. Jag skulle bokstavligen dö utan det här verktyget, så jag rekommenderar det varmt. Det är gratis, så alla kan prova det.

Ben Aston:

Jag ska kolla upp det. Just nu tittar jag på mina olästa e-postmeddelanden: 1 189. Om jag inte har svarat ännu vet du varför. Det hamnar i kolumnen ”att läsa”.

Dimitar Karaivanov:

Ja, det var faktiskt därför vi skapade Flow-e. Det var helt enkelt för smärtsamt att hålla ordning på alla informationsflöden. Så jag rekommenderar det.

Ben Aston:

Då ska jag kolla upp det. Okej, låt oss prata om Kanbanize. Du är vd för Kanbanize och det var din idé tillsammans med det ursprungliga uppstartsteamet. Vi har redan berört vad företaget är: en digital Kanban-tavla som, eftersom den är digital, ger bättre förutsägbarhet, analyser och data samt regler som vi kan använda. Men vilka skulle du säga har den perfekta marknadspassningen? Vilka använder ert verktyg?

Dimitar Karaivanov:

Vi är särskilt utformade för ingenjörsorganisationer. Det kan vara programvaruutveckling, IT- och driftverksamhet eller ingenjörsverksamhet utanför IT, som tillverkning och byggverksamhet. Vi har många framgångsrika kunder inom ingenjörsområdet, men vi används också av marknadsförings- och verksamhetsteam, till exempel inom bank och försäkring. Det passar också mycket bra där. Det handlar i allmänhet om två typer av användningsområden. Projektledning är det jag nyss nämnde – ingenjörsverksamhet – och tjänstehantering gäller exempelvis bank och försäkring. Den typen av kunder passar oss bäst.

Ben Aston:

Ja, fortsätt.

Dimitar Karaivanov:

Det finns en verklig utmaning i projektledning. Projektledare tenderar att planera och uppskatta projekt, och sedan omvandlas planen på något sätt till uppgifter eller arbetsobjekt. De arbetsobjekten finns ofta i ett annat system. Vi har en perfekt plan någonstans i PowerPoint eller Microsoft Project, medan det faktiska arbetet finns i JIRA eller någon annanstans.

Ben Aston:

Precis.

Dimitar Karaivanov:

Hur får man då information om den verkliga statusen? Det finns inget annat sätt än att fråga efter status.

Ben Aston:

Ja.

Dimitar Karaivanov:

Man måste jaga människor: Hur långt har vi kommit? Hur stor procentandel är klar för den här uppgiften? Därför sa vi att vi kunde lösa problemet med Kanban och särskilt med Kanbanize genom att koppla samman planering och genomförande. I Kanbanize har vi ett särskilt lager där man planerar arbetet och ett annat där arbetet genomförs. De två lagren är sammankopplade och skickar återkoppling mellan varandra. När teamet börjar arbeta med något sprids informationen automatiskt till ledningslagret där planen finns. Om vi till exempel ser att planen kommer att misslyckas får projektledaren en avisering och vet direkt att något är fel. I stället för att vänta en vecka, fråga efter status och sedan upptäcka att man är försenad får man aviseringen direkt och kan agera. Det är ganska häftigt.

Ben Aston:

Du får alltså en avisering om att projektet kommer att misslyckas. Det är den artiga varningen som alla fruktar: katastrofen har inträffat och du ligger efter. Jag tror att kärnan i detta uppenbarligen är människorna i teamet. Ett verktyg är bara så bra som människorna som uppdaterar det. Projektledaren måste gå runt till tillräckligt många personer och fråga hur långt de har kommit för att kunna uppdatera sina Gantt-scheman. Men det kräver att de som arbetar i projektet uppdaterar korten själva, inklusive färdigställande och förmodligen tidsregistrering. Av egen erfarenhet av verktyg som JIRA vet jag att människor glömmer att uppdatera kort och statusar. Hur har ni byggt systemet för att ge en aktuell bild av vad människor faktiskt gör och uppmuntra dem att uppdatera statusen?

Dimitar Karaivanov:

Du har rätt, det är ett problem. Lösningen bygger faktiskt på Kanban-metoden. Kanban-metoden är en stor kunskapsmassa. Det handlar inte bara om en whiteboard på väggen. Det finns något som kallas Kanban Maturity Model, som kodifierar mer än 150 vanliga arbetssätt. Om någon är intresserad rekommenderar jag att man tittar på KMM, Kanban Maturity Model, för att förstå vad en mogen Kanban-implementation faktiskt innebär. En del av Kanban-metoden är återkopplingsloopar. Det är regelbundna möten på daglig, veckovis, månadsvis eller kvartalsvis basis. Ett av dessa möten är det dagliga Kanban-mötet eller det dagliga ståmötet, där teamet samlas framför tavlan.

Om det är en digital tavla kan man ha en stor skärm där tavlan visas. Vi går igenom alla kort som för närvarande pågår och pratar om framstegen. Vi pratar inte om personen och vad han eller hon gjorde i går eller gör i dag. Vi pratar om arbetet. Vad har hänt med det här kortet? Har det inte uppdaterats? Behöver det flyttas? Ligger det på rätt plats? På så sätt ser vi till att korten flyttas till rätt position minst en gång om dagen.

Ben Aston:

Det är bra. Jag tycker också att det är intressant att fokusera på arbetet i stället för personen. Många har säkert deltagit i ståmöten där frågorna är: Vad gjorde du i går? Vad ska du göra i dag? Har du några hinder? Vi använder ett verktyg som heter Standuply, som är en bra integration för Slack och ställer frågor till teamet varje dag. Det är ett bra sätt att ha ett asynkront ståmöte. Men människor svarar ofta bara att de arbetade med samma uppgift i går och ska fortsätta med den i dag. Fokuserar man på arbetet i stället för personen får man mer användbar information.

Dimitar Karaivanov:

Jag vill åter hänvisa till KMM. Kanban Maturity Model beskriver sex mognadsnivåer, där varje nivå motsvarar olika arbetssätt – från de enklaste till de mest komplexa. Verktyg som Trello kan ta dig till mognadsnivå ett eller två eftersom de saknar nödvändiga funktioner för en fullt utvecklad Kanban-implementation. Trello saknar till exempel fungerande begränsningar för pågående arbete. Det går att få genom tillägg, men även då är funktionaliteten begränsad. Med ett komplett Kanban-verktyg som Kanbanize kan du begränsa pågående arbete över flera kolumner, horisontella banor, olika tavlor och personer.

När det gäller mätvärden får man inte heller de nödvändiga flödesmåtten direkt ur lådan, till exempel cykeltidskurvor, blockerade arbetsobjekt och Monte Carlo-simuleringar för prognoser baserade på historiskt genomflöde. Sådant kan gå att få genom tillägg, men då är det vanligtvis ett betalt tillägg som ökar kostnaden. Ofta blir det en blandning av funktioner från olika verktyg som inte fungerar särskilt väl tillsammans. Kanbanize är avsett för avancerade Kanban-scenarier, särskilt när man ska skala genom hela organisationen och ge högre chefer möjlighet att fatta välgrundade beslut. Trello är främst ett teamverktyg och fungerar bra för ett team. JIRA bygger däremot mer på Scrum än på Kanbans underliggande mekanism för datainsamling.

I JIRA prognostiserar man utifrån historisk hastighet, alltså de sammanlagda poäng som teamet klarar av sprint efter sprint. Det bygger i stor utsträckning på teamets uppskattningar och magkänsla. I Kanban prognostiserar man utifrån vad som faktiskt har hänt, det historiska genomflödet. Skillnaden kan verka liten, men när man försöker skala en implementation över 20, 30 eller 40 team inser man snabbt att samma antal poäng betyder helt olika saker för olika team. I Kanbanvärlden prognostiserar vi utifrån vad som verkligen har hänt. Det är en grundläggande och mycket viktig skillnad.

Ben Aston:

Om man tar ett övergripande perspektiv på Kanban handlar det om att öka genomflödet genom att minska antalet saker vi arbetar med samtidigt. När vi begränsar pågående arbete försöker vi hjälpa människor att fokusera i stället för att göra sex olika saker samtidigt. Vi vill slutföra en sak och få ut den innan vi delar upp fokus. Alla som arbetar på en byrå med flera kunder känner igen situationen med flera kunder samtidigt och motstridiga deadlines. Kanban bygger på idén att vi kan öka genomflödet och effektiviteten genom att minska antalet saker vi arbetar med, genom att begränsa pågående arbete.

Dimitar Karaivanov:

Du har helt rätt, men det finns en viktig reservation. Om du begränsar pågående arbete för mycket kan du faktiskt hindra genomflödet. Det finns en balans mellan att vara tillräckligt snabb och att ha bästa möjliga genomflöde. Varje organisation måste experimentera och hitta den optimala nivån för sitt sammanhang. När människor frågar vilken begränsning för pågående arbete som är bäst svarar vi alltid att vi inte vet, eftersom vi inte känner till sammanhanget. Man måste experimentera. Du har data till hands, så titta på genomflödet varje vecka. Är det tillfredsställande? Om svaret är ja har du hittat din perfekta nivå.

Ben Aston:

Det är hjälpsamt. Jag är nyfiken på vart Kanbanize är på väg. Vad finns på er färdplan och var tror du att företag befinner sig om fem eller tio år?

Dimitar Karaivanov:

Fem eller tio år är en mycket lång period för mig.

Ben Aston:

Okej, sex veckor då.

Dimitar Karaivanov:

Om sex veckor kan jag definitivt säga att vi kommer att arbeta mot att avlasta projektledaren från fler och fler beslut. I stället för att en person ska behöva beräkna och uppskatta saker samt spela igenom olika tänk-om-scenarier vill vi kunna besvara frågorna direkt ur systemet. Projektledaren ska kunna fokusera mer på det faktiska värdet som skapas och mindre på om värdet kommer att skapas. Vi vill ta över övervaknings- och aviseringsdelen genom särskilda statistiska algoritmer. Varför inte artificiell intelligens? Jag är försiktig med att använda ordet AI eftersom alla talar om AI nu. I det vi gör ger statistiska algoritmer, exempelvis Monte Carlo-simuleringar, bättre precision än de algoritmer som finns. Om någon hävdar att de prognostiserar ett Kanban-system med AI använder de förmodligen inte ren AI eller maskininlärning. Men branschen kommer säkert att röra sig åt det hållet. Vi behöver hitta algoritmer som ger bättre precision än de statistiska algoritmerna. Riktningen är att avlasta projektledarna så att de kan ägna sig åt annat viktigt arbete i stället för övervakning och rapportskrivning.

Ben Aston:

De flesta av våra lyssnare leder projekt eller arbetar som projektledare, kanske även som produktchefer. Hur ser du på utvecklingen av verktyg som Kanbanize, som tar över mer av prognos- och planeringsdelen samt administrationen – att ta reda på vad som händer i ett projekt och rapportera det? Det är ganska tråkigt arbete. I stället talar du om att lägga mer fokus på värdeskapande. Hur förändras och utvecklas projektledarens roll? När du pratar om värdeskapande låter det mer som produktledning och produktägarskap, med fokus på att leverera stegvis värde.

Dimitar Karaivanov:

Jag tycker att projektledaren allt mer bör vara ett gränssnitt som inte bara förmedlar data genom att hantera möten, kommunikationskrav och tidsfrister, utan också berikar informationen och ifrågasätter den. Är det rätt sak vi bygger? Är det rätt tjänst vi producerar? Projektledaren bör vara den som driver systemet mot fortsatt utveckling genom att ställa rätt och svåra frågor. Många projektledare pratar i dag bara med kunden, samlar in kraven, lägger in dem i kravverktyget och skickar dem vidare till utveckling. När utvecklingen är klar går de tillbaka till kunden och säger att arbetet är färdigt.

Det är värdefullt, men bara delvis. Projektledaren bör berika informationsflödet genom att förstå kundens behov, inte bara skriva ett krav. När de inte längre behöver skapa rapporter, hantera tidrapporter och sköta budgetarbete eftersom programvaran gör det, kan de fokusera mer på vad som faktiskt produceras och om det är den bästa lösningen på det underliggande problemet.

Ben Aston:

Vi har talat om projektledningens framtid och hur rollen förändras när vi får bättre data och kan fokusera på att förstå användarnas och kundernas behov samt översätta dem mer korrekt till krav. Vi har också pratat om AI och vikten av precision i verktyg. Hur tror du att landskapet för projektledningsverktyg förändras, och hur anpassar ni er? JIRA har köpt Trello, och det sker en konsolidering. Sedan har vi nya aktörer som ClickUp, som försöker skapa ett system för att hantera allt i en enda lösning.

Dimitar Karaivanov:

Det finns väldigt många verktyg, särskilt för att hantera mindre teams arbete. Jag tror att det finns tusentals sådana. Den som försöker ta sig in på den marknaden måste vara optimist, eftersom det är en stor utmaning. Med Kanbanize gör vi produkten till mer än en lösning för teamhantering. Vi rör oss mot en lösning för agil portföljhantering. Funktionaliteten finns delvis redan, men det är naturligtvis ett mycket stort arbete.

På området agil portföljhantering finns det i praktiken flera stora system som bygger på Scrum. Det är helt okej, men jag tror inte att det är framtiden. Framtiden handlar om att bygga informationsvägar från teamen till ledningen och tillbaka, baserat på vad som faktiskt händer. Verktygslandskapet kommer att konsolideras kring konceptet att skala arbete genom organisationen. Teamverktyg kommer alltid att finnas. Nya verktyg kommer att lösa problem för tre personer men misslyckas i större skala. De kommer och går hela tiden. De verktyg som verkligen vinner är de som löser det stora problemet: hur skapar vi agilitet i hela företaget?

Ben Aston:

Du har skrivit en artikel som heter Kanban Powered Business Agility. Den finns på thedigitalprojectmanager.com och innehåller många tips för att införa ett Kanban-baserat arbetssätt. Jag vill först beröra affärsagilitet. Vad betyder det egentligen för dig?

Dimitar Karaivanov:

För mig innebär affärsagilitet vår förmåga att tillfredsställa marknaden genom snabba lärandecykler och experiment. Det är inte ett ramverk som man implementerar eller en förkortning som man hävdar att man följer. Det är förmågan att experimentera snabbt, lära sig som organisation och använda kunskapen för att skapa mer värde för kunderna. Det är affärsagilitet för mig.

Ben Aston:

Du är en stor förespråkare för Kanban och allt hos er är Kanban-orienterat. Du jämförde nyss Kanban med Scrum. Varför valde du Kanban och varför tycker du att det passar så bra för affärsagilitet? Vad är det bra för och vilka nackdelar ser du?

Dimitar Karaivanov:

Svaret hänger ihop med en av Kanbans principer: börja där du befinner dig och utvecklas sedan genom experiment. Jag känner inte till något alternativ som säger att man ska börja med det man gör i dag och sedan förbättra det om man vill bli mer agil. Andra metoder innebär ofta ett stort språng, omstrukturering av team, certifieringar och omfattande utbildning. Kanban säger i stället: börja där du är, visualisera det som händer på en tavla och ställ sedan frågan hur ni kan göra det bättre.

Jag tycker att det är ett mänskligt sätt att skapa agilitet eftersom det inte orsakar alltför mycket stress i organisationen, åtminstone inte i början. Det kan fortfarande orsaka stress om man gör det fel, men det är en evolutionär process som människor kan förbereda sig på och ta till sig.

Det är därför jag tycker att Kanban är bättre än mycket annat vi känner till i dag: det är ett mänskligt arbetssätt. När det används rätt minskar det stress och överbelastning. Det hjälper människor att uppskatta arbetet, fokusera på några få saker åt gången och göra dem bättre i stället för att ständigt släcka bränder och hoppa mellan olika uppgifter. Den största nackdelen är att människor tror att Kanban bara är en visuell tavla på väggen. Kanban är en omfattande kunskapsmassa och det finns minst ett dussin böcker om ämnet. Jag uppmuntrar alla lyssnare att läsa mer. Det är mycket mer än en whiteboard.

Ben Aston:

Samtidigt är fördelen att många vet vad Kanban är. Om man ber någon förklara Scrum måste man prata om backloggen, sprinten, vilka objekt som ska tas in och alla ceremonier. Kanban kan förklaras mycket enklare. Det är en mer mänsklig och lättare ingång till agilt arbete. Man behöver inte förändra hela leveransramverket, arbeta i sprintar eller införa alla ceremonier. Scrum föreskriver många saker som kan vara hjälpsamma, men det kan vara mycket att ta sig an på en gång. Kanban kan vara en mjukare väg in i effektivare arbetssätt.

Dimitar Karaivanov:

Det är ett mer rimligt sätt att arbeta. Om ett företag har en framgångsrik verksamhet och har lyckats leverera en produkt eller tjänst som kunderna uppskattar måste de redan veta något om hur de bygger och levererar saker. Om vi tar bort den kunskapen eftersom vi tror att vårt ramverk är det bästa på planeten är det arrogant. Det är bättre att först förstå vad företaget faktiskt gör och sedan förbättra det. Det gäller i affärer, skolan och livet i allmänhet.

Ben Aston:

I artikeln pratar du om att förfina arbetsflödet. Man börjar med en lättillgänglig ingång och börjar sedan minska slöseri, arbeta lean och eventuellt begränsa pågående arbete för att fokusera mer och leverera värde snabbare. Hur går den förfiningen av arbetsflödet till i praktiken?

Dimitar Karaivanov:

Vi gör det vanligtvis genom köer och begränsningar av pågående arbete. När man börjar arbeta med en visuell tavla kommer man över tid att se att många kort samlas på ett ställe. Det visar att det finns ett problem i arbetsflödet. Steget kan vara för långsamt eller steget före kan vara för snabbt och översvämma nästa steg med mer arbete än det klarar av.

När det händer bör man stanna upp och reflektera. Varför samlas arbetet här? Man kan exempelvis införa en ny kolumn mellan ”arbete pågår” och ”granskning”, kallad ”redo för granskning”. Om korten samlas där betyder det att granskningen är en flaskhals. Då kan man begränsa det pågående arbetet i kolumnen ”redo för granskning”. När den är full ska den föregående kolumnen sluta producera mer arbete och i stället hjälpa granskarna. Det är den typiska tankeprocessen: ser du att arbete samlas någonstans, inspekterar du, förfinar arbetsflödet vid behov, tillämpar begränsningar och kör sedan igen för att se vad som händer.

Ben Aston:

Målet är alltså att minska flaskhalsarna, så att korten inte samlas i arbete som inte blir färdigt. Värdet skapas i slutändan när saker faktiskt blir klara, inte bara när de flyttas framåt.

Dimitar Karaivanov:

Det ska vi göra kontinuerligt genom att följa cykeltiden. Cykeltiden är den tid korten tillbringar på tavlan innan de faktiskt blir färdiga. Ju kortare cykeltid desto bättre. Om cykeltiden ökar betyder det oftast att arbete samlas på tavlan. Då behöver vi förfina arbetsflödet, begränsa vissa delar och använda köer för att inte överbelasta flaskhalsen. Det gör vi hela tiden.

Ben Aston:

Jag vill också beröra ett annat av dina tips: att omvandla HIPPO till HIPPO. Man måste läsa artikeln för att förstå det, men det handlar om att gå från den högst betalda personens åsikt till alternativet med högst sannolikhet, så att beslut baseras på verkliga data. Hur arbetar du med detta i ditt team, särskilt eftersom du själv är en av de högst betalda personerna i företaget? Hur ber du teamet att säga emot dig när data visar något annat?

Dimitar Karaivanov:

Det är svårt. Jag har gjort många misstag i företaget innan jag nådde den insikten. När jag hör någon fatta ett beslut utifrån magkänsla utan att presentera eller undersöka data börjar jag direkt ställa frågor och utmana personen. Målet är att få dem att fråga sig själva hur de kom fram till slutsatsen och om de kan fatta ett mer välgrundat beslut.

Det är naturligt att människor vill ha rätt. Vi kommer med ett förslag och tror omedelbart att det är det bästa. Jag är själv en person med starka åsikter, och de flesta vd:ar är det. Om jag argumenterar med någon i teamet vinner jag alltid om diskussionen bara handlar om åsikter. Men när data läggs framför mig förändras argumentet, om man är någorlunda rimlig.

Jag har upprepat hundratals gånger för teamet att vi inte ska fatta beslut utifrån magkänsla. Åsikter har vi alla, och om du jämför din åsikt med min förlorar du alltid. Du behöver data. Det fungerar gradvis. Det tar tid att bygga in i företagets DNA, men man måste vara mycket uthållig, kräva data och fortsätta göra det tills arbetssättet sitter.

Ben Aston:

Om någon vill börja prova Kanban och använda det för att skapa affärsagilitet, vad är en bra startpunkt? Du har sagt att man börjar där man befinner sig och att man inte behöver införa stora förändringar omedelbart. Vilka är de första stegen?

Dimitar Karaivanov:

Det finns två eller tre mycket viktiga saker. Den första är att visualisera arbetet. Det kan alla göra utan att bli experter. En fysisk tavla är det uppenbara första valet. Använd post-it-lappar, en tavla och kanske några magneter. Rita några kolumner med en penna. Det tar två minuter, så det finns egentligen ingen ursäkt för att inte visualisera arbetet. Om allt fungerar perfekt behöver man naturligtvis inte ändra något, men om det finns ett problem man vill lösa är det första steget att visualisera arbetet.

Det andra steget är att begränsa pågående arbete. Börja där du är. Om du visualiserar allt och har 100 projekt pågående kan du sätta en begränsning på 100. Det är löjligt högt, men det erkänner åtminstone vad som faktiskt händer. Börja sedan minska antalet pågående projekt tills situationen förbättras.

Det tredje steget, eller kanske det första, är att skaffa utbildning i Kanban från en välrenommerad utbildningsorganisation. Vi samarbetar med Kanban University, som är certifieringsorganisationen bakom Kanban. Det är en global organisation med hundratals utbildare. Jag rekommenderar starkt sådan utbildning. Det kan vara dyrt att utbilda hela företaget, men åtminstone nyckelpersonerna bör få formell utbildning.

Ben Aston:

Det som är värdefullt är det första steget: att visualisera det aktuella arbetsflödet och identifiera problemområdena. Det kan låta svårt, men när man börjar arbeta med teamet är det givande att kartlägga processen. Olika personer kan ha olika bild av hur arbetet rör sig genom organisationen, exempelvis från strategi till UX-design, utveckling, kvalitetssäkring och lansering. De kan också ha olika uppfattningar om godkännanden och granskningscykler. Att visualisera processen gör det lättare att identifiera problem, förstå var flaskhalsar uppstår och fundera på hur man kan begränsa pågående arbete för att öka genomflödet. Tack, Dimitar. Det var mycket hjälpsamt. Om du vill läsa mer om Kanbanize kan du gå till kanbanize.com. Vi lägger länken i programanteckningarna. Dimitar, tack så mycket för att du var med i dag.

Dimitar Karaivanov:

Tack, Ben. Det var roligt att prata med dig. Jag uppskattade samtalet. Låt oss fortsätta.

Ben Aston:

Om du vill lära dig mer och komma vidare i ditt arbete kan du gå med i vår gemenskap genom DPM-medlemskap. Besök thedigitalprojectmanager.com/ membership för att få tillgång till teammallar, workshoppar, A.M.A.-sessioner, kontorstider, e-böcker och mycket mer. Om du tyckte om det du hörde i dag får du gärna prenumerera och hålla kontakten på thedigitalprojectmanager.com. Tills nästa gång – tack så mycket för att du lyssnade.