Slik skaper du smidighet i prosjekter (med Dimitar Karaivanov fra Kanbanize)

Les transkripsjonen:

Vi prøver ut et program for å transkribere podkastene våre. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Ben Aston:

Lean, Scrum, Scrumban, XP, SAFe, DaD, LeSS, DSDM, Kaizen, Kanban. Høres det kjent ut? Dette er bare noen få av rammeverkene som finnes for å levere smidig. Men hva er best, og hvorfor? Fortsett å lytte til denne podkasten for å forstå hvordan du kan skape smidighet i prosjektene dine, og hvilke fordeler en kanban-tilnærming og et kanban-verktøy gir.

Takk for at du lytter. Jeg heter Ben Aston og er grunnlegger av The Digital Project Manager. Velkommen til DPM-podkasten. Vi har som mål å hjelpe prosjektledere med å lykkes og å hjelpe mennesker som leder prosjekter, med å levere bedre. Vi vil hjelpe deg med å ta prosjektarbeidet ditt til neste nivå. Besøk thedigitalprojectmanager.com for å lære mer om opplæringen og ressursene vi tilbyr gjennom medlemskap. Denne podkasten presenteres av Clarizen, ledende leverandør av programvare for virksomhetsomfattende prosjekt- og porteføljestyring. Besøk clarizen.com for å lære mer.

I dag har jeg med meg Dimitar Karaivanov. Dimitar er ingeniør som ble administrerende direktør, og han er medgrunnlegger av Kanbanize. Han er en lean-tenker og kanban-praktiker, og har bakgrunn fra programvareutvikling og prosessforbedring. Han har skrevet et par bøker, blant annet Lean Software Development With Kanban og How Can Portfolio Kanban Benefit Your Business? Jeg tror du forstår bildet. Han brenner for kanban. Hei, Dimitar, og takk for at du blir med oss i dag.

Dimitar Karaivanov:

Ben, takk for invitasjonen. Det er en glede å snakke med deg og lytterne dine. Jeg ser frem til denne podkasten.

Ben Aston:

Det er flott å ha deg med. Du brenner tydeligvis virkelig for kanban, og du har bygget et helt produkt rundt Kanbanize. Men i rollen som administrerende direktør er jeg nysgjerrig på hva det faktisk innebærer. Hvordan ser en typisk dag ut for deg som administrerende direktør og medgrunnlegger av Kanbanize?

Dimitar Karaivanov:

Som administrerende direktør i et selskap, særlig et selskap som befinner seg i en sen oppstartsfase, må du ha mange ulike roller. Jeg snakker vanligvis med mange kunder, siden jeg ofte trer inn i rollen som produktleder.

Ben Aston:

Riktig.

Dimitar Karaivanov:

Deretter snakker jeg med utviklingsavdelingen for å videreformidle tilbakemeldingene vi har fått fra kundene. Jeg arbeider også med salg til virksomheter. Og selvfølgelig bruker jeg tid på strategi når tiden tillater det, fordi dette er en viktig del av det administrerende direktører gjør. Strategi kan for øvrig også anvendes med kanban, så kanskje vi bør finne noen minutter til å snakke om det.

Ben Aston:

Ja, absolutt. Men før vi går inn på det, er jeg nysgjerrig på bakgrunnshistorien din. Hvordan begynte du å lage programvare for prosjektstyring?

Dimitar Karaivanov:

Det skjer vanligvis fordi det oppstår et behov. Jeg var endringsagent i et stort tysk selskap. Vi gikk fra fossefallsprosesser til smidige prosesser, og vi flyttet rundt 500 personer fra den gamle måten å gjennomføre prosjekter på, over til Scrum. Vi lærte opp alle i Scrum. Vi hadde en rekke smidige team, 25 eller flere, men oppdaget at selv om teamene til en viss grad klarte å levere stabilt, var det kaos på ledelsesnivået, der de større arbeidselementene befant seg – i vårt tilfelle funksjoner, epikker og lignende. Jeg innså at vi manglet verktøy for å håndtere både teamnivået og ledelses- og koordineringsnivået. Slik ble Kanbanize faktisk til, med målet om å skalere smidig arbeid på tvers av organisasjonen.

Ben Aston:

Kult. Da dere startet et prosjektstyringsverktøy og bygget det fra grunnen av, må dere ha hentet inspirasjon fra andre verktøy dere likte, og også fra verktøy dere ikke likte, fordi dere mente at dere måtte bygge deres eget. Hvor kom den opprinnelige inspirasjonen fra?

Dimitar Karaivanov:

Vi brukte JIRA i det selskapet. Det er den store 300-punds-Godzillaen du finner overalt. Det inneholder mye bra, men den visuelle delen, særlig for åtte eller ni år siden, var enten helt fraværende eller svært begrenset. Selv om det inneholdt mange gode konsepter, kom den egentlige inspirasjonen vår til hvordan vi skulle skalere kanban og smidig arbeid på tvers av organisasjonen, i større grad fra et fysisk kanban-tavle. Med Kanbanize forsøkte vi å etterligne hvordan man visualiserer arbeidet på en fysisk kanban-tavle, med den store fordelen at den er digital og kan kobles til flere andre team, samtidig som dataene kan samles slik at ledelsen kan se dem og ta informerte beslutninger. Det er egentlig to verktøy: JIRA og fysiske kanban-tavler.

Ben Aston:

Riktig. Og siden dere lager deres eget prosjektstyringsverktøy, er jeg interessert i hvilke andre verktøy Kanbanize integreres med, eller hvilke dere bruker parallelt med Kanbanize for å styre selskapet.

Dimitar Karaivanov:

Jeg ville ikke klart meg uten Microsoft Teams, som jeg tror er den raskest voksende applikasjonen i internetthistorien. Jeg bruker mye tid i Teams, særlig nå som vi alle arbeider eksternt. Deretter bruker jeg sannsynligvis halve dagen i et verktøy som heter Flow-e. Det finnes på flow-e.com, og overraskende nok er det et verktøy fra vårt eget selskap. Det er Kanbanize for e-post. Det er et visualiseringslag oppå Outlook-e-posten din som gjør innboksen om til en kanban-tavle, slik at du kan visualisere e-postene dine og følge samtaler i en kanban-lignende visning. Det er en livredder for meg. Jeg ville bokstavelig talt dødd uten dette verktøyet, så jeg anbefaler det. Det er gratis, så alle kan prøve det.

Ben Aston:

Jeg skal sjekke det ut. Jeg ser på e-postene mine nå. For øyeblikket har jeg 1189 uleste e-poster. Hvis jeg ikke har svart ennå, vet du hvorfor. Den kan legges i kolonnen «skal leses».

Dimitar Karaivanov:

Ja, det var nettopp derfor vi laget Flow-e. Det var for smertefullt å holde oversikt over alle informasjonsstrømmene. Derfor anbefaler jeg det.

Ben Aston:

La oss snakke om Kanbanize. Dere har en digital kanban-tavle som gir bedre forutsigbarhet, analyser og data, i tillegg til regler vi kan bruke. Hvem er den ideelle målgruppen deres?

Dimitar Karaivanov:

Vi er spesifikt utviklet for ingeniørvirksomheter. Det kan være programvareutvikling, IT- og driftsavdelinger, eller ikke-IT-relaterte ingeniørmiljøer som produksjon og bygg. Vi har mange vellykkede kunder innen ingeniørfagene, men brukes også av markedsførings- og driftsteam, for eksempel i banker og forsikringsselskaper. Det finnes i hovedsak to brukstilfeller: prosjektstyring innen ingeniørfag og tjenestestyring innen bank og forsikring.

Ben Aston:

Ja, fortsett.

Dimitar Karaivanov:

Prosjektledere planlegger og estimerer prosjekter, og planen blir deretter omgjort til oppgaver eller arbeidselementer. Disse elementene ligger ofte i et annet system. Vi har en perfekt plan i PowerPoint eller Microsoft Project, mens det faktiske arbeidet ligger i JIRA eller et annet sted. Hvordan får du da informasjon om den reelle statusen? Du må gå og spørre om status. Deretter må du mase på folk: Hvor langt har vi kommet? Hvor mange prosent er denne oppgaven ferdig? Vi sa at dette kunne løses med kanban, og mer spesifikt Kanbanize, ved å koble sammen planlegging og gjennomføring. Vi har ett lag der du planlegger arbeidet, og et annet der du utfører det, men de to lagene er koblet sammen og sender tilbakemeldinger til hverandre. Når teamet begynner å arbeide med noe, videreformidles informasjonen automatisk til ledelseslaget der planen ligger. Hvis vi for eksempel ser at planen kommer til å mislykkes, varsler vi prosjektlederen automatisk. I stedet for å vente en uke, be om status og oppdage at du ligger etter, får du et varsel og kan handle med en gang.

Ben Aston:

Det er en høflig advarsel: «Prosjektet ditt kommer til å mislykkes.» Det må være e-posten alle gruer seg til. Men dette avhenger selvsagt av at folk i teamet oppdaterer verktøyet. Hvordan har dere bygget systemet for å få et sanntidsbilde av hva folk faktisk gjør, og for å oppmuntre dem til å oppdatere statusen?

Dimitar Karaivanov:

Du har rett, det er et problem. Løsningen er å støtte seg på kanban-metoden. Kanban-metoden er en stor kunnskapsbase, ikke bare en tavle på veggen. Det finnes også noe som heter Kanban Maturity Model, som beskriver mer enn 150 vanlige praksiser. Jeg anbefaler alle interesserte å se nærmere på KMM, Kanban Maturity Model, for å forstå hva en moden kanban-implementering innebærer. Et viktig element i kanban-metoden er tilbakemeldingssløyfer. Dette er regelmessige møter på daglig, ukentlig, månedlig eller kvartalsvis basis. I det daglige kanbanmøtet eller standup-møtet går teamet gjennom tavlen.

Hvis det er en digital tavle, kan dere ha en stor skjerm med tavlen vist på den. Vi går gjennom hvert kort som er under arbeid og snakker om fremdriften. Vi snakker ikke om personen og hva vedkommende gjorde i går eller i dag. Vi snakker om arbeidet: Hva har skjedd med dette kortet? Er det oppdatert? Må det flyttes? Ligger det på riktig plass? På den måten sørger vi for at kortene flyttes til riktig plass minst én gang om dagen.

Ben Aston:

Det er bra. Jeg synes også det er interessant at fokuset ligger på arbeidet i stedet for personen. Mange standup-møter handler om hva du gjorde i går, hva du skal gjøre i dag, og om du har hindringer. Det kan være nyttig, men ofte får man bare høre at noen fortsetter med den samme oppgaven. Å fokusere på arbeidet i stedet for personen er derfor et godt tips.

Dimitar Karaivanov:

Kanban Maturity Model beskriver seks modenhetsnivåer, og hvert nivå tilsvarer ulike praksiser, fra de enkleste til de mest komplekse. Verktøy som Trello kan kanskje ta deg til nivå én eller to, fordi de mangler nødvendige funksjoner for en fullverdig kanban-implementering. Trello mangler for eksempel fungerende grenser for pågående arbeid. I et verktøy som Kanbanize kan du begrense pågående arbeid på tvers av kolonner, horisontale baner, tavler og personer. Det er stort fokus på kanban-funksjoner.

Når det gjelder måltall, får du heller ikke nødvendigvis flytmåltallene du trenger, som syklustidskurver, blokkeringer og Monte Carlo-simuleringer for prognoser basert på historisk gjennomstrømning. Slike funksjoner kan finnes som tillegg, men tilleggene koster ofte ekstra og fungerer ikke alltid godt nok. Kanbanize er utviklet for avanserte kanban-scenarioer, særlig når arbeidet skal skaleres på tvers av organisasjonen og ledelsen skal kunne ta informerte beslutninger. Trello er et teamverktøy som fungerer godt for ett team. Kanbanize er laget for større skala.

Ben Aston:

På et overordnet nivå handler kanban om å øke gjennomstrømningen ved å redusere antall ting vi arbeider med samtidig. Når vi begrenser pågående arbeid, sørger vi for at folk fokuserer mer og fullfører én ting før de går videre. Hvis vi reduserer antall ting vi arbeider med, kan vi øke gjennomstrømningen og effektiviteten.

Dimitar Karaivanov:

Det stemmer, men det finnes en viktig nyanse. Hvis du begrenser pågående arbeid for mye, kan du faktisk hindre gjennomstrømningen. Det finnes en balanse mellom å være rask og å oppnå best mulig gjennomstrømning. Hver organisasjon må eksperimentere for å finne det optimale nivået for sin egen kontekst. Vi vet ikke hva den beste grensen er før vi har sett på dataene. Du må undersøke gjennomstrømningen hver uke og se om den er tilfredsstillende. Hvis den er det, har du funnet en god grense.

Ben Aston:

Det er nyttig. Hvor er Kanbanize på vei, og hva står på veikartet deres?

Dimitar Karaivanov:

Vi ønsker i stadig større grad å avlaste prosjektlederen fra beslutninger og beregninger. I stedet for at en person må beregne, estimere og spille ut «hva om»-scenarioer, ønsker vi å besvare slike spørsmål automatisk. Prosjektlederen skal kunne konsentrere seg mer om den faktiske verdien som skapes, ikke bare overvåking og rapportering. Vi ønsker å overta overvåkings- og varslingsdelen ved hjelp av statistiske algoritmer, for eksempel Monte Carlo-simuleringer. Jeg er forsiktig med å bruke ordet kunstig intelligens, fordi statistiske algoritmer i mange av tilfellene våre gir bedre nøyaktighet enn eksisterende KI-algoritmer. Men bransjen beveger seg definitivt i den retningen.

Ben Aston:

Hvordan ser du for deg at prosjektlederrollen utvikler seg når verktøy tar over mer av prognose- og planleggingsarbeidet?

Dimitar Karaivanov:

Prosjektlederen bør i stadig større grad være grensesnittet som ikke bare videreformidler data og håndterer kommunikasjon, frister og krav, men også beriker dataene og stiller spørsmål ved dem. Er dette det riktige vi bygger? Er dette den riktige tjenesten vi produserer? Prosjektlederen bør være personen som driver systemet videre ved å stille de riktige og vanskelige spørsmålene. Når rapportering, timelister og budsjettering avlastes av programvaren, kan prosjektlederen konsentrere seg mer om det som faktisk produseres, og om det er den beste løsningen på det underliggende problemet.

Ben Aston:

Hvordan ser du på konkurranselandskapet for prosjektstyringsverktøy, med aktører som JIRA, Trello og ClickUp?

Dimitar Karaivanov:

Det finnes svært mange verktøy, særlig for å håndtere arbeidet til mindre team. Kanbanize utvikler seg fra å være en løsning for teamstyring til å bli en løsning for smidig porteføljestyring. Det er et stort arbeid, men det er her vi mener fremtiden ligger: i å bygge informasjonsveier fra teamene til ledelsen og tilbake igjen. Teamverktøy vil alltid eksistere, men de store vinnerne blir verktøyene som løser problemet med å skape smidighet på virksomhetsnivå.

Ben Aston:

Du har skrevet artikkelen Kanban Powered Business Agility. Hva betyr virksomhetssmidighet for deg?

Dimitar Karaivanov:

For meg betyr virksomhetssmidighet evnen til å tilfredsstille markedet gjennom raske læringssykluser, eksperimentering og anvendelse av det vi lærer. Det er ikke et rammeverk man implementerer eller en forkortelse man hevder å følge. Det handler om evnen til å eksperimentere raskt, lære som organisasjon og bruke denne kunnskapen til å skape mer verdi for kundene.

Ben Aston:

Hvorfor mener du at kanban passer godt for virksomhetssmidighet?

Dimitar Karaivanov:

Svaret henger sammen med et av kanban-prinsippene: Start der du er, og utvikle deg eksperimentelt. Hvis du ønsker å bli mer smidig eller forbedre virksomhetssmidigheten, bør du begynne med det du gjør nå og forbedre det gradvis. Kanban sier: Start der du er. Visualiser det som skjer på en tavle, og spør deretter hvordan dere kan gjøre det bedre. Det er en menneskelig tilnærming til smidighet fordi den ikke skaper for mye stress i organisasjonen fra starten av. Når den gjennomføres riktig, reduserer den stress og overbelastning, hjelper folk med å fokusere på færre ting om gangen og gjør det lettere å få glede av arbeidet.

Ben Aston:

Hvordan skjer egentlig forbedringen av arbeidsflyten?

Dimitar Karaivanov:

Vi gjør dette gjennom køer og grenser for pågående arbeid. Når du begynner å arbeide med en visuell tavle, vil du over tid kunne se at kort samler seg opp et sted. Det tyder på at dette punktet i arbeidsflyten er problematisk. Det går enten for sakte, eller så produserer trinnet foran for mye arbeid. Da bør du stoppe opp, undersøke situasjonen og spørre hvorfor arbeidet samler seg opp der. Kanskje må du innføre en ny kolonne, for eksempel «klar for gjennomgang» mellom «under arbeid» og «gjennomgang». Hvis kortene samler seg i denne kolonnen, er gjennomgangsfasen en flaskehals. Da kan du begrense det pågående arbeidet i kolonnen. Når den er full, bør den forrige kolonnen slutte å produsere mer arbeid og heller hjelpe gjennomgangsteamet. Du undersøker, forbedrer arbeidsflyten ved behov, innfører grenser for pågående arbeid og ser hva som skjer. Dette gjør du hele tiden.

Ben Aston:

Målet er altså å redusere flaskehalsene, slik at arbeidet faktisk blir ferdigstilt og verdi skapes.

Dimitar Karaivanov:

Ja. Vi bør gjøre dette kontinuerlig ved å følge med på syklustiden. Syklustid er tiden kortene tilbringer på tavlen før de faktisk er ferdige. Jo kortere syklustid, desto bedre. Når syklustiden øker, betyr det sannsynligvis at arbeid samler seg på tavlen. Da bør vi forbedre arbeidsflyten, begrense noen kolonner og bruke køer for å unngå å overbelaste flaskehalsen.

Ben Aston:

Et annet råd du gir, handler om å gå fra HIPO-er til HIPPO-er: fra den best betalte personens mening til den høyest sannsynlige løsningen, basert på reelle data. Hvordan får du dette til i teamet ditt?

Dimitar Karaivanov:

Når jeg hører noen ta en beslutning basert på magefølelse uten å presentere eller undersøke data, begynner jeg å stille spørsmål. Jeg utfordrer dem til de selv spør: Hvordan kom jeg frem til denne konklusjonen? Kan jeg ta en mer informert beslutning? Alle ønsker å ha rett, og jeg er selv en svært meningssterk person. Hvis jeg diskuterer med noen i teamet, vinner jeg ofte fordi jeg er administrerende direktør. Men når dataene viser noe annet, må diskusjonen endres. Jeg har gjentatt hundrevis av ganger at vi ikke skal ta beslutninger basert på magefølelse. Meninger taper alltid mot data. Det har tatt tid å bygge dette inn i selskapets DNA, men man må være svært konsekvent og kreve data hver gang.

Ben Aston:

Hva er et godt utgangspunkt for noen som vil prøve kanban?

Dimitar Karaivanov:

Det er to eller tre svært viktige ting. Først bør du visualisere arbeidet. Alle kan gjøre dette uten å bli eksperter. En fysisk tavle er et naturlig førstevalg. Du trenger bare lapper, en tavle og noen kolonner. Det tar to minutter, så det finnes egentlig ingen unnskyldning for ikke å visualisere arbeidet. Hvis det finnes et problem du ønsker å løse, er visualisering det første steget.

Steg nummer to er å begrense pågående arbeid. Start der du er. Hvis du visualiserer alt og har 100 prosjekter pågående, kan du sette grensen til 100. Det er svært høyt, men det gjenspeiler i det minste virkeligheten. Deretter kan du gradvis redusere antallet prosjekter til ting blir bedre.

Det tredje steget er å skaffe god kanban-opplæring. Jeg anbefaler at nøkkelpersonene får formell opplæring, selv om det kan bli dyrt å lære opp hele selskapet.

Ben Aston:

Det er et svært nyttig råd. Det første steget er å visualisere den nåværende arbeidsflyten og identifisere smertepunktene. Når teamet kartlegger prosessen, kan ulike personer oppdage at de har forskjellig oppfatning av hvordan arbeidet faktisk beveger seg gjennom organisasjonen – fra strategi via UX-design, utvikling og kvalitetssikring til lansering. Visualisering gjør det lettere å identifisere hvor ting går galt, hvor flaskehalsene oppstår, og hvordan vi kan begrense pågående arbeid for å øke gjennomstrømningen. Takk, Dimitar. Dette var svært nyttig. Hvis du vil sjekke ut Kanbanize, kan du besøke kanbanize.com. Tusen takk for at du ble med oss i dag.

Dimitar Karaivanov:

Takk, Ben. Det var veldig hyggelig å snakke med deg. Jeg satte stor pris på samtalen. La oss fortsette.

Ben Aston:

Hvis du vil lære mer og komme videre i arbeidet ditt, kan du bli med i fellesskapet vårt gjennom DPM-medlemskap. Besøk thedigitalprojectmanager.com/ membership for tilgang til teammaler, verksteder, A.M.A.-økter, kontortid, e-bøker og mer. Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com. Men frem til neste gang: Tusen takk for at du lyttet.