Sådan skaber du agilitet i projekter (med Dimitar Karaivanov fra Kanbanize)

Læs transskriptionen:

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle tastefejl, da botten ikke er korrekt 100 % af tiden.

Ben Aston:

Lean, Scrum, Scrumban, XP, SAFe, DaD, LeSS, DSDM, Kaizen, Kanban. Lyder det bekendt? Det er blot nogle få af de rammeværk, der findes til agil levering. Men hvad er bedst, og hvorfor? Lyt videre til denne podcast for at forstå, hvordan du kan skabe agilitet i dine projekter, samt fordelene ved en kanban-tilgang og et kanban-værktøjssæt.

Tak, fordi du lytter med. Jeg hedder Ben Aston og er grundlægger af The Digital Project Manager. Velkommen til DPM-podcasten. Vi har som mission at hjælpe projektledere med at få succes og hjælpe folk, der leder projekter, med at levere bedre resultater. Vi er her for at hjælpe dig med at tage dine projektledelseskompetencer til næste niveau. Besøg thedigitalprojectmanager.com for at lære mere om den træning og de ressourcer, vi tilbyder gennem medlemskab. Denne podcast præsenteres af Clarizen, førende inden for software til virksomhedsprojekt- og porteføljestyring. Besøg clarizen.com for at få mere at vide.

I dag har jeg selskab af Dimitar Karaivanov. Dimitar er ingeniør, der er blevet administrerende direktør, og han er medstifter af Kanbanize. Han er lean-tænker og kanban-praktiker og har en baggrund inden for softwareudvikling og procesforbedring. Han har skrevet et par bøger: Lean Software Development With Kanban og How Can Portfolio Kanban Benefit Your Business? Jeg tror, du forstår pointen. Han brænder for Kanban. Så hej Dimitar, og tak fordi du vil være med i dag.

Dimitar Karaivanov:

Ben, tak fordi du inviterede mig. Det er en fornøjelse at tale med dig og dit publikum. Jeg ser frem til denne podcast.

Ben Aston:

Ja, det er fantastisk at have dig med. Du brænder tydeligvis virkelig meget for Kanban, og du har bygget et helt produkt omkring Kanbanize. Men i din rolle som administrerende direktør er jeg nysgerrig efter at vide, hvad det faktisk betyder. Hvordan ser en typisk dag ud for dig som administrerende direktør og medstifter af Kanbanize?

Dimitar Karaivanov:

Som administrerende direktør i virksomheden, især i en virksomhed, der befinder sig på et sent startup-stadie, bærer man mange hatte. Jeg taler typisk med mange kunder, fordi jeg ofte udfylder rollen inden for produktledelse.

Ben Aston:

Okay.

Dimitar Karaivanov:

Derefter taler jeg med udviklingsafdelingen for at viderebringe den feedback, vi har fået fra kunderne. Jeg arbejder også med salg til virksomheder. Og selvfølgelig arbejder jeg med strategi, når tiden tillader det, fordi det er en vigtig del af det, administrerende direktører laver. Strategi kan i øvrigt også anvendes sammen med Kanban, så måske bør vi finde et par minutter til at tale om det.

Ben Aston:

Ja, helt sikkert. Men før vi går i dybden med det, er jeg nysgerrig efter at forstå lidt mere om din baggrund. Hvordan begyndte du at udvikle software til projektledelse?

Dimitar Karaivanov:

Det sker typisk ud af et behov. Jeg var forandringsagent i en stor tysk virksomhed. Vi var i gang med at gå fra vandfaldsprocesser til agile processer, og vi flyttede omkring 500 mennesker fra den gamle måde at gennemføre projekter på over til Scrum. Scrum var normen for enhver ny agil implementering. Vi uddannede alle i Scrum. Vi havde en masse agile teams, 25 eller flere, men vi opdagede, at selv om teamene nogenlunde kunne levere stabilt, var det et rod på ledelsesniveauet, hvor de større arbejdsdele befandt sig, og i vores tilfælde var det funktioner, epics og den slags. Jeg fandt ud af, at vi manglede værktøjer til at håndtere både teamniveauet og ledelses- og koordinationsniveauet. Det var faktisk sådan, Kanbanize blev født, med målet om at skalere agilitet på tværs af organisationen.

Ben Aston:

Fedt. Da I startede et projektledelsesværktøj fra bunden og byggede det, må I have hentet inspiration fra andre værktøjer, som I kunne lide, og også fra værktøjer, I ikke kunne lide, fordi I tænkte, at I selv var nødt til at bygge et. Hvor kom den oprindelige inspiration fra?

Dimitar Karaivanov:

Vi brugte JIRA i den virksomhed. Det er den store Godzilla på 300 pund, uanset hvor man går hen. Det indeholder en masse gode ting. Men denne del, især for otte eller ni år siden, var, hvis den ikke var helt fraværende, så meget begrænset. Selvom det indeholder mange gode koncepter, kom den egentlige inspiration til, hvordan vi kunne skalere Kanban og agilitet på tværs af organisationen, faktisk mere fra et fysisk kanban-board. Det, vi gjorde med Kanbanize, var at forsøge at efterligne, hvordan man visualiserer sit arbejde på et fysisk kanban-board, med den store fordel, at det er digitalt, og at man kan forbinde det med flere andre teams og samle data, så ledelsen kan se dem og træffe informerede beslutninger. Det er faktisk to værktøjer: JIRA og fysiske kanban-boards.

Ben Aston:

Okay. I har selvfølgelig jeres eget projektledelsesværktøj, men jeg er interesseret i at finde ud af, hvilke andre værktøjer Kanbanize integrerer med, eller hvilke værktøjer I bruger parallelt med Kanbanize til at lede virksomheden. Er der nogle værktøjer, som fungerer godt for jer, eller som I netop har opdaget og synes er ret gode?

Dimitar Karaivanov:

Ja, jeg ville ikke undvære Microsoft Teams, fordi jeg tror, det er den hurtigst voksende applikation i internettets historie. Det er et stærkt værktøj, som vi også bruger sammen med Kanbanize. Jeg bruger meget tid i Teams, især i disse dage, hvor vi alle arbejder på afstand. Derefter bruger jeg nok halvdelen af min dag i et værktøj, der hedder Flow-e. Det findes på flow-e.com, og overraskende nok er det et værktøj fra vores egen virksomhed. Det er Kanbanize til din e-mail. Det er et visualiseringslag oven på din Outlook-e-mail, som forvandler din indbakke til et kanban-board, hvor du kan visualisere dine e-mails og føre samtaler i en kanban-lignende visning. Det er en livredder for mig. Jeg ville bogstaveligt talt dø uden dette værktøj, så jeg kan anbefale det. Det er gratis, så alle kan prøve det.

Ben Aston:

Det vil jeg undersøge. Min skærm viser lige nu 1.189 ulæste e-mails. Hvis jeg ikke har svaret endnu, ved du hvorfor. Det kommer i kolonnen "skal læses".

Dimitar Karaivanov:

Ja, det var faktisk sådan, vi fandt på Flow-e. Det var simpelthen for smertefuldt at holde styr på alle informationsstrømmene. Så jeg anbefaler det.

Ben Aston:

Det vil jeg tjekke. Cool. Lad os tale om Kanbanize. Du er naturligvis administrerende direktør i Kanbanize, og det var din idé sammen med resten af det oprindelige startup-team. Vi har allerede berørt, hvad virksomheden er: et digitalt kanban-board, som giver bedre forudsigelighed, analyser og data samt nogle regler, vi kan bruge. Men hvem vil du sige er det perfekte markedsmatch? Hvem bruger jeres værktøj?

Dimitar Karaivanov:

Vi er specifikt designet til ingeniørvirksomheder. Det kan være softwareudvikling, IT- og driftsafdelinger eller ikke-IT-relaterede ingeniørbrancher som produktion, byggeri og lignende. Vi har mange succesfulde kunder inden for ingeniørområdet, men vi bruges også af marketingteams og driftsteams, for eksempel i banker eller forsikringsselskaber. Det er også et godt match. Det er generelt to typer anvendelser: projektledelse, som er det, jeg netop nævnte inden for ingeniørarbejde, og serviceledelse, som typisk ses i banker og forsikringsselskaber. Det er de kundetyper, der passer bedst. Når vi taler om projektledelse, vil jeg gerne uddybe det, hvis du ønsker det. Det gælder mennesker, som gerne vil forstå de specifikke ting ved Kanbanize.

Ben Aston:

Ja, gør endelig det.

Dimitar Karaivanov:

Der er en reel udfordring i min erfaring. Vi ser, at projektledere har en tendens til at planlægge projekter og estimere projekter, hvorefter planen på en eller anden måde omdannes til opgaver eller arbejdselementer, som typisk lever i et andet system. Så vi har en perfekt plan et sted i PowerPoint eller i Microsoft Project, mens det faktiske arbejde ligger i JIRA eller et andet sted.

Ben Aston:

Ja.

Dimitar Karaivanov:

Hvordan får man så oplysninger om den faktiske status? Der er ingen anden måde end at spørge efter status.

Ben Aston:

Ja.

Dimitar Karaivanov:

Og så skal man forstyrre folk. Hvor langt er vi nået? Hvor stor en procentdel er denne opgave færdig? Og alt det der. Så vi sagde: Vi kan løse dette problem med Kanban og specifikt med Kanbanize ved at forbinde planlægningen med udførelsen. Vi har et særligt lag i Kanbanize, hvor man planlægger arbejdet, og et særligt lag, hvor man udfører arbejdet. Men de to lag er forbundet, og de sender feedback fra det ene til det andet. Når teamet begynder at arbejde på noget, bliver oplysningerne automatisk overført til ledelseslaget, hvor planen ligger. Hvis vi for eksempel kan se, at planen kommer til at mislykkes, underretter vi projektlederen, som automatisk ved, at noget er galt. I stedet for at vente en uge, spørge efter status og derefter opdage, at man bliver forsinket, får man blot denne meddelelse og kan handle på den. Det er ret smart.

Ben Aston:

Man får en meddelelse om, at projektet kommer til at mislykkes. Det er en høflig advarsel. Det må være den e-mail, som alle frygter. Katastrofen er indtruffet. Man er nu bagud. Men det er smart. Jeg tror, kernen i det selvfølgelig er menneskene i teamet, og det er en udfordring ved alle værktøjer: De er kun så gode, som de mennesker, der opdaterer dem. Den udfordring, du løser, er, at projektlederen skal gå rundt til tilstrækkeligt mange mennesker og spørge: Du arbejder på denne opgave. Hvor langt er du nået, så jeg kan opdatere mine Gantt-diagrammer og på den måde finde ud af, hvordan projektet skrider frem? Men det kræver, at de involverede i projektet selv opdaterer kortene med færdiggørelsen, og jeg går ud fra, at tidsregistrering også er en del af det. Min erfaring med værktøjer som JIRA er, at folk glemmer at opdatere kort og statusser. Hvordan har I bygget systemet, så det kan håndtere det og give et realtidsbillede af, hvad folk rent faktisk laver, samtidig med at de opfordres til at opdatere statusserne?

Dimitar Karaivanov:

Du har ret. Det er et problem. Måden, man løser det på, er faktisk ved at basere sig på kanban-metoden. Kanban-metoden er en stor vidensbase. Det er ikke bare et whiteboard på væggen. Der findes en hel model, der hedder Kanban Maturity Model, som beskriver mere end 150 almindelige praksisser. Hvis nogen er interesserede, bør de undersøge KMM, Kanban Maturity Model, så de kan se, hvad en moden kanban-implementering faktisk indebærer. Når det er sagt, er der én ting i kanban-metoden, der hedder feedback-sløjfer. Feedback-sløjfer er regelmæssige møder, som afholdes dagligt, ugentligt, månedligt eller kvartalsvist. Et af disse møder er det daglige kanban-møde eller det daglige ståmøde, hvor teamet samles foran boardet.

Hvis det er et digitalt board, kan man have en stor skærm med boardet vist på den. Vi gennemgår hvert af de kort, der i øjeblikket er i gang, og taler om fremdriften. Vi taler ikke om personen og om, hvad vedkommende lavede i går eller i dag. Vi taler om arbejdet. Hvad er der sket med dette kort? Er det ikke blevet opdateret? Skal det flyttes et sted hen? Er det placeret rigtigt? På den måde sikrer vi, at kortene mindst én gang om dagen flyttes til den rigtige position.

Ben Aston:

Det er godt. Jeg synes også, det er interessant, at fokus ligger på arbejdet frem for personen. Lytterne har sikkert deltaget i ståmøder, hvor jeg ofte ser dette. Vi bruger et værktøj, der hedder Standuply, som er en virkelig god integration til Slack, og som stiller teamet spørgsmål hver dag: Hvad lavede du i går? Hvad laver du i dag? Har du nogen blokeringer? Det er en god måde at holde et asynkront ståmøde på. Så prøv Standuply. En udfordring ved det er dog, at folk ofte siger det samme, både i virkeligheden og på Slack. Hvad lavede du i går? Hvad laver du i dag? De nævner den samme opgave: at bygge en widget. Hvad er dine blokeringer? Ingen. Og så tænker man: Okay, det hjalp ikke rigtigt. Vi har ikke fået mere indsigt i, hvad der foregår. Derfor er det et nyttigt tip at fokusere på arbejdet frem for personen, der bare gentager sin sætning om, hvad vedkommende arbejder på. Tak for det. Men når vi taler om, at du brugte JIRA, og at JIRA har købt Trello, som også er et kanban-værktøj, er jeg nysgerrig efter at vide, hvordan du ser Kanbanize i forhold til andre værktøjer.

Dimitar Karaivanov:

Jeg vil igen henvise til KMM. Kanban Maturity Model taler om seks modenhedsniveauer, hvor hvert niveau svarer til forskellige praksisser, fra de enkleste til de mest komplekse. Værktøjer som Trello kan føre dig til modenhedsniveau et eller to, fordi de mangler de nødvendige funktioner til en fuldt udviklet kanban-implementering. Trello mangler for eksempel fuldstændigt fungerende begrænsninger for igangværende arbejde. Man kan få dem med en tilføjelse, men selv da er de blot begrænsede. Med et ordentligt kanban-værktøj som Kanbanize kan man begrænse igangværende arbejde på tværs af flere kolonner, horisontale baner, forskellige boards og personer. Der er virkelig stor vægt på de kanban-lignende funktioner.

Når vi taler om målinger, får man heller ikke de nødvendige flowmålinger direkte fra værktøjet, for eksempel cyklustidskurver, blokeringer eller Monte Carlo-simuleringer til prognoser baseret på historisk gennemløb. Man kan få det, men det er altid gennem en tilføjelse. Det er normalt en betalt tilføjelse, som lægger ekstra omkostninger oveni. Og helt ærligt fungerer det sjældent godt nok. Det bliver bare en blanding af funktioner fra forskellige værktøjer, der er sat sammen. Jeg kan sammenfatte det sådan, at Kanbanize virkelig er beregnet til avancerede kanban-scenarier, især når vi taler om at skalere på tværs af organisationen og gøre det muligt for den øverste ledelse at træffe informerede beslutninger. Trello er mere et teamværktøj, som er godt til ét team. Hvis man går ud over det, ved jeg ikke, om det overhovedet er muligt med JIRA. Det er muligt, men det er mere baseret på Scrum end på den underliggende mekanisme til dataindsamling i Kanban. I JIRA laver man prognoser baseret på sin historiske hastighed, altså det samlede antal point, man kan levere sprint for sprint. Men det er helt baseret på teamets prognoser og mavefornemmelse. I Kanban laver man prognoser baseret på det, der faktisk er sket, nemlig ens historiske gennemløb.

Det kan ligne en meget lille forskel, men hvis man forsøger at gennemføre implementeringen på 20, 30 eller 40 teams, opdager man hurtigt, at ét team kan mene noget helt andet med 20 point end et andet team. Så er man nødt til at normalisere, og tre point bliver et fuldstændigt mareridt, der helt ærligt ikke fungerer. I kanban-verdenen laver vi prognoser baseret på, hvad der faktisk sker. Det er en grundlæggende forskel, og efter min mening er den meget vigtig.

Ben Aston:

Hvis vi tager et overordnet blik på Kanban, taler Dimitar om nogle af de underliggende principper, og om hvordan Kanbanize passer godt til dem. Kanban-systemet bygger grundlæggende på idéen om, at vi skal øge gennemløbet ved at minimere antallet af ting, vi arbejder på på samme tid. Når vi taler om at begrænse igangværende arbejde, forsøger vi at sikre, at folk er mere fokuserede og ikke prøver at gøre seks forskellige ting, men faktisk færdiggør én ting og får den ud ad døren, før de går videre.

Alle, der nogensinde har arbejdet i et bureau med flere kunder, kender sikkert scenariet, hvor flere kunder håndteres samtidig, og hvor deadlines konflikter med hinanden. Idéen med Kanban er, at hvis vi reducerer antallet af ting, vi arbejder på, kan vi øge gennemløbet og effektiviteten i den måde, vi arbejder på. Det gør vi ved at begrænse det igangværende arbejde. Det er et meget vigtigt princip i Kanban: Lad os fokusere på færre ting, så får vi faktisk mere fra hånden.

Dimitar Karaivanov:

Du har helt ret. Der er blot én vigtig undtagelse: Hvis man begrænser igangværende arbejde for meget, kan man faktisk hæmme gennemløbet. Der er en fin balance mellem at være hurtig og have det bedst mulige gennemløb. Hver organisation må eksperimentere og finde det niveau for igangværende arbejde, der er optimalt for netop deres situation. Folk spørger ofte: Hvad er den bedste grænse for igangværende arbejde? Vi siger altid, at det ved vi ikke, fordi vi ikke kender konteksten. Man er nødt til at eksperimentere. Man har data lige ved hånden, så man kan se på gennemløbet hver uge. Er det tilfredsstillende? Hvis det er, har man fundet sin perfekte implementering.

Ben Aston:

Det er nyttigt. Jeg er nysgerrig efter at høre, hvor Kanbanize er på vej hen. Hvad står på jeres køreplan? Hvor ser du virksomheder være om fem eller ti år?

Dimitar Karaivanov:

Fem eller ti år er meget lang tid i mit hoved, men jeg kan fortælle dig, hvad der sker de næste seks uger.

Ben Aston:

Okay, seks uger.

Dimitar Karaivanov:

Vi bevæger os i retning af i stigende grad at aflaste projektlederen for de beslutninger, der skal træffes. I stedet for at en person skal beregne ting, lave estimater og afprøve forskellige scenarier, vil vi gerne besvare disse spørgsmål direkte fra systemet. Projektlederen skal kunne fokusere mere på den faktiske værdi, der skabes, og mindre på, om vi kommer til at skabe denne værdi. Vi vil derfor overtage overvågnings- og underretningsdelen ved at indføre specifikke statistiske algoritmer. Hvorfor ikke kunstig intelligens? Jeg er meget forsigtig med at bruge ordet kunstig intelligens, fordi alle taler om det nu, mens statistiske algoritmer som Monte Carlo-simuleringer faktisk giver bedre nøjagtighed end de algoritmer, der findes. Hvis nogen påstår, at de laver prognoser for et kanban-system baseret på kunstig intelligens, bruger de sandsynligvis ikke ren kunstig intelligens eller maskinlæring. Men jeg tror helt sikkert, at branchen bevæger sig i den retning. Vi skal finde algoritmer, der giver bedre nøjagtighed end de statistiske algoritmer. Det handler om at aflaste projektlederne, så de kan udføre andet vigtigt arbejde i stedet for blot at overvåge og skrive salgsrapporter.

Ben Aston:

Lad os tale om det. De fleste af vores lyttere er mennesker, der leder projekter, projektledere eller måske også produktledere. Hvordan ser du værktøjer som Kanbanize overtage mere af prognose- og planlægningsdelen af arbejdet? Det administrative arbejde med at finde ud af, hvad der sker i et projekt, og rapportere det, kan være ret kedeligt. Du taler i stedet om at fokusere mere på værdiskabelse. Hvordan ser du projektlederens rolle ændre og udvikle sig? Når du taler om værdiskabelse, lyder det for mig mere som produktledelse og produktejerskab, hvor man fokuserer på at levere trinvis værdi. Hvordan ser du den rolle udvikle sig?

Dimitar Karaivanov:

Jeg mener, at projektlederen i stigende grad bør være den grænseflade, der ikke blot viderebringer data og håndterer kommunikationskrav og deadlines, men også beriger dataene og stiller spørgsmål: Bygger vi det rigtige? Producerer vi den rigtige service? For mig bør projektlederen være den person, der skubber systemet videre i dets udvikling ved at stille de rigtige og vanskelige spørgsmål. Mange projektledere taler i dag kun med kunden, indhenter kravene, lægger dem i kravværktøjet og sender dem videre til udviklingen. Når udviklingen er færdig, går de tilbage til kunden og siger: Dette er færdigt. Lad os se, hvordan vi leverede det.

Det er værdifuldt, men kun delvist værdifuldt. Jeg mener, at disse mennesker skal berige datakanalen ved at forstå kundens behov og ikke blot skrive et krav. Når de har tid til det, fordi de ikke længere skal producere rapporter, følge op på timesedler og lave budgetter, når dette arbejde er overtaget af den software, de bruger, kan de fokusere meget mere på, hvad der faktisk bliver produceret, og om det er den bedste løsning på det underliggende problem bag denne funktionsanmodning.

Ben Aston:

Det lyder som en god plan. Jeg vil gerne spørge dig om fremtiden for projektledelse, og hvordan vores rolle ændrer sig, efterhånden som vi får bedre data og kan fokusere på at forstå brugernes og kundernes behov og omsætte dem mere præcist til krav, så vi sikrer, at vi leverer værdi. Vi har talt om kunstig intelligens og betydningen af nøjagtighed i værktøjer. Hvordan ser du overordnet landskabet for projektledelsesværktøjer ændre sig, og hvordan tilpasser I jer det? Vi har aktører som JIRA, der har købt Trello, og vi ser konsolidering. Vi har også nyere startup-værktøjer som ClickUp, der forsøger at skabe et system til at håndtere alt, en kanban- og alt-i-en-løsning. Hvordan ser du det konkurrenceprægede landskab ændre sig, og hvordan tilpasser I jer?

Dimitar Karaivanov:

Du har ret. Der findes et væld af værktøjer, især til håndtering af arbejdet i mindre teams. Jeg tror, der findes tusindvis af dem. Hvis nogen forsøger at trænge ind på det marked, må de være optimister, for det er en reel udfordring. Det, vi gør med Kanbanize, er at udvikle produktet fra ikke blot at være en løsning til teamledelse, men til faktisk at blive en løsning til agil porteføljestyring. Funktionaliteten er delvist på plads, men det er naturligvis en enorm opgave. Det tager mange år at bygge, og vi er kun et stykke gennem arbejdet.

På området for agil porteføljestyring får man grundlæggende en række store systemer, der er afhængige af Scrum. Det synes jeg er fint, men jeg tror ikke, det bliver fremtiden. Fremtiden handler efter min mening om at bygge på det, der faktisk sker, og om at skabe informationsveje fra teamene til den øverste ledelse og tilbage igen. Kort sagt tror jeg, at værktøjslandskabet konsolideres omkring idéen om at skalere arbejdet på tværs af organisationen. Teamværktøjer vil altid eksistere. Der kommer hele tiden nye værktøjer med en fantastisk brugeroplevelse, som løser problemet for tre personer, men ikke løser det i større skala. De kommer og går. Det er givet. Men de store vindere bliver dem, der løser det enorme problem: Hvordan skaber vi agilitet i hele virksomheden?

Ben Aston:

Lad os tale om det. Du har skrevet en artikel, som hedder Kanban-drevet forretningsagilitet. Den kan læses på thedigitalprojectmanager.com og indeholder en række tips til at implementere en kanban-tilgang. Først vil jeg dog gerne berøre forretningsagilitet, for jeg tror, det er det, du netop talte om. Hvad betyder det egentlig for dig? Hvad er forretningsagilitet?

Dimitar Karaivanov:

For mig betyder forretningsagilitet vores evne til at tilfredsstille markederne gennem hurtige læringscyklusser, eksperimenter og anvendelse af det, vi lærer. Forretningsagilitet er ikke et rammeværk, man implementerer, eller en forkortelse, man påstår, man følger. Det er evnen til hurtigt at eksperimentere, lære som organisation og derefter bruge denne viden til at skabe mere værdi for kunderne. Det er for mig forretningsagilitet.

Ben Aston:

Du er tydeligvis en stor fortaler for Kanbanize – eller rettere Kanban. Du har kaldt Kanbanize efter Kanban, og alt er orienteret mod Kanban. For lidt siden sammenlignede du Kanban med Scrum. Hvorfor valgte du Kanban, og hvorfor mener du, at det egner sig bedst til forretningsagilitet? Hvad er det godt til, og hvad anerkender du, at det ikke er godt til?

Dimitar Karaivanov:

Det er et godt spørgsmål. Svaret hænger sammen med et af Kanbans principper, som siger: Begynd dér, hvor du er, og udvikl dig derefter gennem eksperimenter. Der er ingen anden tilgang, jeg kender, som siger, at hvis du vil være agil eller forbedre din forretningsagilitet, skal du begynde med det, du gør nu, og derefter forbedre det. Det kræver ofte et stort spring at blive bedre. Man omstrukturerer teams, tager certificeringer og sender folk på agile kurser. Kanban siger blot: Begynd dér, hvor du er. Visualiser det, der sker nu, på et board, og spørg derefter: Hvordan kan vi gøre dette bedre? Jeg synes, det er en menneskelig tilgang til agilitet, fordi den ikke skaber for meget stress i organisationen, i hvert fald ikke i begyndelsen. Den kan skabe meget stress, hvis man gør det forkert, men det er en evolutionær proces. Folk bliver forberedt på den og tager den til sig. Det er min erfaring.

Jeg tror, det er grunden til, at virksomheder foretrækker det frem for alt andet, vi kender i dag: Det er en menneskelig tilgang. Når man gør det rigtigt, reducerer det stress og overbelastning blandt de mennesker, der arbejder i organisationen. Det er endnu en grund til, at Kanban er menneskeligt: Det hjælper folk med at nyde det arbejde, de udfører. Det hjælper dem med at fokusere på nogle få ting ad gangen, gøre dem bedre og undgå konstant at slukke brande og skifte fra én ting til en anden. Det er det, jeg tror. Hvad angår de dårlige sider, er jeg ikke sikker på, at de skyldes Kanban. Det største problem er, at folk tror, det blot er et visuelt board på væggen. Jeg har allerede sagt flere gange, at Kanban er en omfattende vidensbase. Der er skrevet mindst et dusin bøger om Kanban, så jeg opfordrer lytterne til at undersøge det. Der er meget mere i det end et whiteboard.

Ben Aston:

På nogle måder er fordelen ved det dog, at mange mennesker ved, hvad Kanban er. Hvis man beder nogen om at forklare Scrum eller Kanban, kan Kanban forklares i sin enkleste form langt hurtigere og lettere end Scrum, hvor man skal forklare, at der er en backlog, et sprint, at man skal trække elementer ind, og at der sker forskellige ting. Der er ceremonier og en masse regler. Det er et rammeværk, som du siger, jeg godt kan lide at beskrive som en mere menneskelig eller lettere indgang til den agile verden. Man behøver ikke fuldstændigt ændre sin leverancemodel. Man behøver ikke arbejde i sprints eller afholde forskellige ceremonier. Scrum dikterer mange ting, som kan være nyttige, men det kan være meget at tage ind på én gang og kræve en stor omlægning af processen. Kanban kan være en blødere indgang til at arbejde mere effektivt.

Dimitar Karaivanov:

Jeg synes faktisk, det er mere rimeligt. Hvis vi kommer udefra uden at forstå konteksten og siger: Du skal gøre dette, så bliver du bedre, kan det være lidt arrogant. Hvis en virksomhed har en succesfuld forretning og har formået at levere et produkt eller en service, som kunderne sætter pris på, må de vide noget. De ved noget om, hvordan de bygger og leverer ting. Hvis vi kommer og fjerner denne viden, fordi vi tror, at vores rammeværk er det bedste på planeten, er det arrogant. Det er meget bedre at sige: Lad os se på, hvad I præcis gør, og derefter forbedre det. Det er efter min mening den bedre tilgang i livet, i forretning og i skolen.

Ben Aston:

I dit indlæg taler du om at forfine arbejdsgangen, hvilket er det, du beskriver her. Vi finder et let tilgængeligt udgangspunkt, kommer i gang og begynder derefter at forfine tingene. Vi vil reducere spild, være lean og måske reducere det igangværende arbejde, så vi kan fokusere bedre og levere værdi hurtigere og mere effektivt. Men hvordan foregår denne forfinelse af arbejdsgangen egentlig? Det er nemt at sige, men hvordan forfiner man den?

Dimitar Karaivanov:

Vi gør det typisk gennem det, vi kalder køer og begrænsninger for igangværende arbejde. Når man begynder at arbejde på et visuelt board, vil man over tid, hvis man er grundig og endnu ikke er særlig moden inden for Kanban og lean, sandsynligvis se en række kort hobe sig op et sted på boardet. Det kan være et tegn på et problematisk sted i arbejdsgangen. Enten er det for langsomt, eller også går trinnet før det for hurtigt og oversvømmer det næste trin med mere arbejde, end det kan nå at håndtere. Når man ser en sådan situation, bør man stoppe op og reflektere. Hvorfor hober arbejdet sig op her?

Det, der typisk sker, er, at vi indfører nye kolonner, de såkaldte klar-kolonner. Vi kan have en proces med "i gang", "gennemgang" og "færdig", men vi indfører en kolonne mellem "i gang" og "gennemgang", der hedder "klar til gennemgang". Derefter kan vi se, om kortene i "klar til gennemgang" hober sig op. Hvis de gør, betyder det, at gennemgangsfasen er en flaskehals og ikke kan følge med den mængde arbejde, som den foregående kolonne producerer. Vi kan så begrænse det igangværende arbejde i kolonnen "klar til gennemgang". Når den er fuld, bør den foregående kolonne stoppe med at producere mere arbejde og hjælpe dem, der gennemfører gennemgangen. Det er den typiske tankeproces. Ser man arbejde hobe sig op, inspicerer man, forfiner arbejdsgangen efter behov, anvender begrænsninger for igangværende arbejde efter behov og kører derefter videre for at se, hvad der sker. Det gør man hele tiden.

Ben Aston:

Målet er altså at reducere flaskehalsene, så kortene ikke hober sig op, og arbejdet ikke forbliver ufærdigt. Det er i sidste ende, når tingene bliver færdige, at værdien skabes, ikke nødvendigvis når de blot flyttes videre.

Dimitar Karaivanov:

Netop. Vi bør gøre dette konstant, samtidig med at vi observerer cyklustiden. Cyklustiden er den tid, kortene tilbringer på boardet, før de faktisk bliver færdige. Jo kortere cyklustid, desto bedre. Når vi overvåger målingerne og ser cyklustiden vokse, betyder det højst sandsynligt, at arbejdet hober sig op på boardet. Så skal vi forfine arbejdsgangen, begrænse nogle kolonner og bruge køer for at sikre, at vi ikke overbelaster flaskehalsen. Det skal vi gøre hele tiden.

Ben Aston:

Jeg vil gerne berøre endnu et af dine tips: at omdanne HIPO'er til HIPO'er. Man er nødt til at læse indlægget for at forstå det, men det handler grundlæggende om at ændre den højest lønnede persons mening til den mulighed, der har den højeste sandsynlighed, så man bruger faktiske data til at træffe beslutninger. Jeg er nysgerrig efter at høre, hvordan dette spiller ind i dit team og i din rolle som administrerende direktør. Du er sandsynligvis en af de højest lønnede personer i virksomheden. Hvad er dit råd til dit eget team, hvis de får besked på at ændre kurs? Det er svært, når man er en del af teamet og siger: Det handler ikke om den højest lønnede persons mening. Lad os se på, hvad dataene viser. Hvordan ville du som administrerende direktør bede dit team om at præsentere det?

Dimitar Karaivanov:

Det er ærligt talt svært. Jeg har begået så mange fejl i vores virksomhed for at nå frem til denne erkendelse. Der er virkelig blevet spildt mange penge. Det, jeg forsøger at gøre med vores teams, er, at når jeg hører nogen træffe en beslutning ud fra mavefornemmelsen uden at præsentere eller observere data, begynder jeg straks at stille spørgsmål og udfordre dem, indtil de selv spørger: Hvordan nåede jeg egentlig frem til denne konklusion? Kan jeg træffe en mere informeret beslutning?

Det er naturligt, at mennesker gerne vil have ret. Alle vil have ret. Vi fremsætter et forslag og tror straks, at det er det bedste forslag på planeten. Jeg er selv en meget holdningspræget person, og det tror jeg, de fleste administrerende direktører er. Hvis jeg diskuterer med nogen fra mit team, vinder jeg altid. Men når der kommer data på bordet, og dataene bliver holdt op foran mig, ændrer argumentet sig, hvis man er bare en smule fornuftig.

Jeg har gentaget det hundredvis af gange over for mine teams: Lad os ikke træffe beslutninger ud fra mavefornemmelser. Det er bare meninger. Vi har alle meninger. Hvis du vil sammenligne din mening med min mening, taber du altid. Så du må hellere have data. Det virker til en vis grad. Det er en overgangsperiode, og det har taget os lang tid. Jeg tror, det er vores andet eller tredje år, hvor vi forsøger at indarbejde det fuldstændigt i vores virksomheds DNA. Det er virkelig svært, men vi tror på det. Det er en praksis, der skal gentages 10.000 gange, før den sidder fast. Det korte svar er, at man skal være meget vedholdende. Man skal kræve data. Hvis man glider, vender folk tilbage til de gamle vaner.

Ben Aston:

Som afslutning: Hvis jeg var der, og dit indlæg handlede om forretningsagilitet og om, hvordan Kanban kan være med til at styrke den, hvad vil du så sige til en person, der gerne vil prøve Kanban? Hvad er et godt udgangspunkt? Du sagde tidligere, at Kanban accepterer, at det sted, hvor man begynder at blive mere agil, er dér, hvor man allerede befinder sig. Det betyder ikke nødvendigvis, at man straks skal indføre omfattende ændringer i processen. Hvad er et af de første skridt mod at blive mere agil gennem en kanban-tilgang?

Dimitar Karaivanov:

Jeg vil sige, at der er to eller tre meget vigtige ting. En af dem er at visualisere arbejdet. Det kan vi alle gøre. Vi behøver ikke være eksperter for at visualisere vores arbejde. Man skal blot finde en måde at gøre det på. Et fysisk board er det oplagte første valg. Man skal bruge nogle sticky notes, et board og måske magneter, tegne nogle kolonner med en tusch, og så har man det på to minutter. Der er virkelig ingen undskyldning for ikke at visualisere arbejdet. Det gælder selvfølgelig, hvis der er en kilde til utilfredshed. Hvis alt er perfekt, hvorfor så ændre noget? Men hvis der er et problem, man gerne vil løse, er trin et: Visualiser arbejdet.

Trin to er at begrænse det igangværende arbejde. Begynd i det mindste dér, hvor du er. Hvis du visualiserer alt og har 100 projekter i gang, så sæt grænsen til 100. Det er absurd højt, men det anerkender i det mindste, hvad der faktisk foregår. Begynd derefter at reducere antallet af igangværende projekter, indtil tingene bliver bedre. Og trin tre – eller måske endda trin et – er, at jeg vil anbefale folk at få noget ordentlig Kanban-træning på højt niveau. Vi er partnere med Kanban University, som er certificeringsorganet bag Kanban. Det er en verdensomspændende organisation med hundredvis af undervisere. Jeg vil stærkt anbefale sådan en træning. Det kan være lidt dyrt at uddanne hele virksomheden, men de vigtigste personer bør efter min mening som minimum gennemføre en formel uddannelse.

Ben Aston:

Jeg synes, det, du taler om, er meget værdifuldt: Det første skridt er at visualisere den nuværende arbejdsgang og identificere problemerne. Det kan lyde meget svært, men når man først går i gang, er det bestemt givende at kortlægge den sammen med teamet. Man opdager måske, at forskellige personer har forskellige opfattelser af den nuværende proces og af, hvordan arbejdet bevæger sig gennem organisationen. Det kan bevæge sig fra strategi gennem UX-design, udvikling, kvalitetssikring og udgivelse.

Man vil sandsynligvis opdage, at forskellige mennesker har forskellige opfattelser af godkendelsesprocessen eller gennemgangscyklusserne. Derfor er det meget nyttigt først at visualisere processen. Derefter kan man lettere identificere problemerne: Hvor går tingene galt? Hvor opstår flaskehalsene? Det kan hjælpe med at overveje, hvordan man begrænser det igangværende arbejde, så man kan øge gennemløbet. Tak, Dimitar. Det var meget nyttigt. Hvis du vil se Kanbanize, kan du gå til kanbanize.com. Vi indsætter det i shownoterne. Dimitar, mange tak fordi du ville være med i dag. Det har været fantastisk at have dig med.

Dimitar Karaivanov:

Tak, Ben. Jeg sætter pris på invitationen. Det var virkelig sjovt at tale med dig. Jeg nød samtalen. Lad os fortsætte.

Ben Aston:

Hvis du vil lære mere og komme foran i dit arbejde, kan du slutte dig til vores fællesskab med et DPM-medlemskab. Gå til thedigitalprojectmanager.com/ medlemskab for at få adgang til vores teamskabeloner, workshops, AMA-sessioner, kontortider, e-bøger og meget mere. Hvis du kunne lide det, du hørte i dag, så abonnér, og hold kontakten på thedigitalprojectmanager.com. Men indtil næste gang: Mange tak for denne gang.