Slik får du smidig arbeidsmetodikk til å fungere effektivt i byråer

Les transkripsjonen:

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

Galen Low: Hei alle sammen, og takk for at dere lytter. Jeg heter Galen Low og er fra The Digital Project Manager. Vi er et fellesskap av digitale fagfolk med et mål om å hjelpe hverandre med å bli dyktigere, tryggere og bedre knyttet sammen, slik at vi kan øke verdien av prosjektledelse i en digital verden. Hvis du vil høre mer om dette, kan du gå til thedigitalprojectmanager.com.

I dag skal vi snakke om realitetene ved å få smidig arbeidsmetodikk til å fungere i en byråkontekst. Det er et stort spørsmål vi ofte får i fellesskapet vårt. Derfor skal vi undersøke hvorfor det er så vanskelig å lykkes med smidig arbeidsmetodikk, og hva byråer må gjøre for å få den til å fungere for seg.

Med meg i dag har jeg Dave Prior, sertifisert Scrum-trener hos LeadingAgile og en anerkjent tankeleder innen smidig arbeidsmetodikk. I over 15 år har han hjulpet organisasjoner med å navigere overgangen til smidig arbeidsmetodikk med så lite smerte som mulig.

Dave, det er en ære å ha deg med i programmet.

Dave Prior: Det er flott å være her, og det var en fantastisk åpning. Den var så mye bedre enn min. Jeg sier vanligvis bare hei.

Galen Low: Jeg har mye øvelse. Jeg sier til alle jeg tar opp med at jeg gjør det hver gang. Så til dere som lytter på podkasten: Dere tror kanskje at det bare er et opptak, men nei, vi gjør det direkte hver gang. Det er oppvarmingen min.

Dave Prior: Det har jeg sett, og det er svært godt gjennomført. Veldig godt gjennomført.

Galen Low: Skål. Vel, skål.

Dave Prior: Men takk for at du inviterte meg.

Galen Low: Nei, det er flott å ha deg med. Jeg sa i pauserommet at jeg spurte fellesskapet vårt hvem jeg burde invitere til podkasten. Alle svarte uten tvil: Dave Prior. Så det er en stor ære. Smidig arbeidsmetodikk er et stort tema, særlig blant prosjektlederne våre i byråene. Mange strever med det.

Det er på en måte noe mystisk som har eksistert en stund, men som fortsatt er ganske vanskelig å få helt grep om. Derfor tenkte jeg at vi kunne begynne å utforske det i dag og se hvor samtalen fører oss. Ja, for å sette scenen: Smidig arbeidsmetodikk har eksistert i over 20 år. Det startet med programvareutvikling.

Men den dag i dag forteller mange av dem jeg snakker med, som arbeider i digitale byråer og konsulentselskaper, at organisasjonene deres fortsatt sliter med å få rammeverk som Scrum og andre former for smidig arbeidsmetodikk til å passe inn i forretningsmodellen. Derfor tenkte jeg å undersøke dette i dag, men før vi går inn i det, vil jeg spørre deg: Hva fikk deg interessert i smidig arbeidsmetodikk i utgangspunktet? Hva var det ved smidig arbeidsmetodikk som trakk deg inn?

Dave Prior: La meg se. Jeg jobbet i et digitalt byrå i New York og arbeidet med en netthandelsløsning. Dette var helt i begynnelsen av netthandelen. Man måtte bygge alt fra grunnen av. Vi brukte ett år på kravspesifikasjon. Prosjektet var en total katastrofe.

Jeg antar at teknologidirektøren hadde lest den første utgaven av «Extreme Programming Explained». Overgangen vår til smidig arbeidsmetodikk besto i at han gikk inn i rommet der teamet satt, kastet en bunke bøker på gulvet og sa: «Les dette i løpet av helgen, så jobber dere smidig på mandag.» Det ble en total katastrofe. Derfor ville jeg ikke ha noe med smidig arbeidsmetodikk å gjøre.

Jeg trodde det bare var en samling unnskyldninger for at prosjektledere skulle slippe å planlegge og utviklere skulle slippe å forplikte seg. Jo mer jeg arbeidet med prosjektledelse, desto mer gikk jeg i motsatt retning. Jeg ble dratt, sparkende og skrikende, inn i smidig arbeidsmetodikk. Jeg var altså ikke en som så det og tenkte: «Dette ser kult ut.» Jeg så det og tenkte: «Dette er søppel.»

Og jeg kjempet imot i veldig lang tid. Så begynte jeg med rådgivning, og da jeg ikke lenger klarte å kjempe imot, ga jeg etter og så at det fungerte. Men for meg var det ikke før jeg så det fungere i praksis at jeg tenkte: «Å nei, dette er faktisk noe.» Men jeg tror det er veldig vanskelig hvis man kommer fra et tradisjonelt prosjektledelsesperspektiv. Det er nesten som å bytte religion.

Galen Low: Rettferdig. Jeg liker virkelig det perspektivet, at du ikke umiddelbart drakk Kool-Aid-en. Du gransket det, og det var først da du så at det fungerte, at du endret syn. Jeg liker det perspektivet, særlig når jeg tenker tilbake på historien din om den første erfaringen med smidig omstilling: Les disse bøkene i helgen, og så setter vi i gang.

Dave Prior: Det fungerte ikke særlig bra.

Galen Low: Du og jeg er store tilhengere av at alt på papiret og i teorien kan se fantastisk ut. Men når virkeligheten møter veien, og man faktisk skal få ting til å skje, er det der beviset ligger. Og jeg antar at det andre er at folk har sett smidig arbeidsmetodikk gå galt.

Selv om de drakk Kool-Aid-en med en gang da de leste om det, og deretter gikk inn i et prosjekt som ble gjennomført med noe som Scrum og så at det ble en katastrofe, er det en annen ting som skaper mange som sier: «Nei, dette fungerer faktisk ikke.»

Dave Prior: Ja. Folk som meg misforsto mye av det jeg leste. Jeg brukte halve tiden på å fortelle folk at det ikke kom til å fungere, og resten av tiden på å sabotere det, slik at det ikke kunne fungere. Og det var ikke alltid med vilje. Jeg hadde lært tradisjonell prosjektledelse. Jeg trodde man planla alt, fant ut av alt.

Og hvis de dumme utviklerne bare gjorde det jeg sa, ville alt ordne seg. Jeg tenkte ikke over at kunden som kommer inn døren og sier «Jeg trenger denne tingen», ikke engang vet hva problemet deres er når de forteller deg løsningen. Det er som å gå inn på apoteket og si: «Jeg trenger den medisinen», uten å ha snakket med noen om hva som faktisk feiler meg.

Galen Low: Nettopp. Og noen ganger får man feil medisin.

Dave Prior: Ja, da skjer det dårlige ting.

Galen Low: Du nevnte at du nå veileder folk og hjelper organisasjoner med smidige omstillinger. For organisasjonene du hjelper, hva er det viktigste de prøver å oppnå ved å ta i bruk smidig arbeidsmetodikk? Hva ønsker de å få ut av det, og har de grunn til å forvente dette?

Dave Prior: Jeg tror det er det første og viktigste spørsmålet enhver organisasjon bør besvare. Dessverre tenker de ikke engang på å stille spørsmålet. Smidig arbeidsmetodikk er som cellegift, ikke sant? Hvis fossefallsmodellen er en dødelig sykdom, kan smidig arbeidsmetodikk gjøre deg bedre, men først vil den gjøre deg sykere.

Mange selskaper velger smidig arbeidsmetodikk fordi alle andre gjør det, fordi de så et SAFe-diagram og syntes det så kult ut, eller fordi de tror de trenger det for å være konkurransedyktige, uten å vite hvorfor. Hvis du driver et selskap, kan du tenke på det slik: Du ansetter smidig arbeidsmetodikk for å utføre en jobb. Hvilken jobb trenger du at den skal gjøre?

Hva skal den fikse for deg? Og hva er du villig til å ofre for å få det til? Det kommer ikke uten ofre og smerte. Jeg tror det er det viktigste folk glemmer å spørre om. Jeg har folk i kursene mine hele tiden som spør: «Hvorfor gjør selskapet ditt dette?» Og svaret er: «Jeg vet ikke, det var det vi måtte gjøre.»

Byråer føler at de må gjøre det fordi det fortsatt er det som er populært, og fordi de må kunne si at de jobber smidig. Men svært få av dem gjør det faktisk, fordi de prøver å presse det inn i en fossefallsmodell.

Galen Low: Det er som markedsføring, og det du sa om å holde seg konkurransedyktig, treffer meg veldig. Det finnes en oppfatning på stedene jeg har jobbet og blant menneskene jeg har snakket med, om at hvis du ikke jobber smidig, er du en dinosaur. Jeg har mine egne meninger om det, men det er tankegangen i disse byråene: «Selvfølgelig jobber vi smidig. Vi gjør det riktig. Ansett oss.»

Fordi vi skal sørge for at vi bygger det riktige, og at vi foreskriver riktig medisin for det du ønsker. Vi vet at du ikke har funnet alle svarene ennå, og du trenger ikke finne dem alle. Bare kom inn. Men som vi har antydet, finnes det utfordringer i hvordan denne omstillingen skjer.

Dave Prior: Folk snakker hele tiden om kultur når det gjelder smidig arbeidsmetodikk, og sier at man må begynne med kulturen. Kultur er svært viktig, men hvis du ikke skaper et miljø der noe som Scrum kan overleve, kommer det ikke til å fungere. Folk kommer på kurset mitt, og jeg sier: «Greit, gå tilbake og fortell teamet ditt at dere bare skal arbeide med ett produkt for én kunde om gangen.»

Og de svarer: «Jeg er på 13 prosjekter, det kan jeg ikke.» Hvis du ikke skaper rommet der det kan vokse, kommer det ikke til å fungere. Det tenker de ikke over. Jeg tror det finnes sider ved byråenes forretningsmodell som er lagt opp slik at den får dette til å mislykkes, med mindre man gjør svært betydelige endringer.

Galen Low: La oss gå inn i det, for jeg er enig med deg i at man må skape en kultur som støtter smidig arbeidsmetodikk. Hvor ser du at dette kommer i konflikt med kulturen i selve byråmodellen?

Dave Prior: Jeg arbeidet med noe for TPM Summit. Jeg holdt foredrag der et par ganger, og brukte omtrent et helt år på å intervjue ulike selskaper og byråer om hvordan de hadde innført smidig arbeidsmetodikk, i håp om å finne et sted som faktisk hadde lykkes.

Jeg fant to som hadde gjort det. Jeg fant også ett som hadde erklært at de var selskapet for smidig omstilling i digitale byråer, men alt de gjorde, var usmidig.

Galen Low: Interessant.

Dave Prior: Hvis et digitalt byrå, med røtter i reklame, er organisert slik at man har massevis av kunder som bruker evigheter på å godkjenne ting, selv om de sa at de ikke skulle gjøre det, og alle må være fakturerbare minst hundre prosent av tiden for at forretningsmodellen skal overleve, får man ikke den graden av fokus som kreves for å gjøre dette.

I tillegg kommer det at selgerne belønnes for en signatur, ikke for evnen til å levere. De selger alt. Så viser det seg at vi ikke har nok folk til å gjøre arbeidet. «Vi legger det på planen deres likevel.» Dermed mangler man alltid ressurser og tid, og teamene får ikke rom til å finne ut hvordan de skal få det til å fungere.

De får ikke rom til å lære å kommunisere slik de trenger. De er alltid stresset av enorme tidsfrister som er urettferdige og urealistiske. De eneste stedene jeg har sett lykkes, har endret hele forretningsmodellen for å få den til å passe med smidig arbeidsmetodikk. Det følger også smerte med det.

Galen Low: Hvordan ser det ut? Nå må jeg nesten spørre.

Dave Prior: I det ene tilfellet måtte også selgerne gjennom Scrum-opplæring. Hvis du ser på hele verdistrømmen, fra du leverer sluttproduktet til kunden og helt tilbake til salget, må du sørge for at dette er balansert.

Det handler ikke bare om at vi har alle disse menneskene på alle disse prosjektene. Før vi signerer en kontrakt, må vi spørre: Har vi kapasitet til å levere? Forklarte vi kunden at dersom vi arbeider smidig, er dette det vi trenger fra dem, og dette er graden av forpliktelse de må ha? De endret modellen slik at alle ble en del av den smidige prosessen.

Og gruppene ble belønnet etter evnen til å levere. Salgsavdelingen får ikke bonus hvis det ikke finnes et team som faktisk kan produsere arbeidet. Dermed anerkjenner man avhengigheten, og man må planlegge rundt den. Det betyr at man må takke nei til noe arbeid. Kanskje må man ta mer betalt eller finne en annen løsning.

Galen Low: Det er et stort kulturskifte, ikke sant? Den stereotypiske byråmodellen er at alle er hundre prosent fakturerbare, eller kanskje 80–100 prosent i enkelte byråer. Ideen er at vi har ansatte, vi må holde dem opptatt, og pengene må fortsette å strømme inn. Alle insentivene er rettet mot dette.

Salgsprosessen handler om å signere mer arbeid for å fylle opp alle ressursene våre. Selv i prosjektet er insentivene knyttet til fakturerbare timer. Det finnes vanligvis ikke særlig mye motivasjon for å gjøre noe raskere enn det normalt ville tatt, fordi man ønsker å få det til å passe inn i estimatet.

Og man vil ikke sitte med hendene i fanget, for da er man uten oppdrag, og det er alltid fullt. Det som traff meg i det du sa, var dette med fokus. Jeg hadde egentlig ikke tenkt over det, men det krever fokus å endre seg. Dette er grunnleggende sett et spørsmål om endringsledelse.

Hvis man ikke gir folk nok rom til å finne seg til rette i endringen, men i stedet har en presset strøm av prosjekter som kommer inn, og man arbeider med 10–13 prosjekter samtidig uten å få en sjanse til å finne ut av det, føles det sannsynligvis bare som å arbeide med 13 katastrofer.

Dave Prior: Det som gjør det enda verre, er at kundene dine ikke arbeider smidig. Et av selskapene jeg snakket med, hadde faktisk klart å få det til. Jeg sa til mannen: «Hvis jeg var kunden din, måtte du lære meg å være produkteier.» Han svarte ja. Jeg sa: «Jeg får betalt for å gjøre det. Det bryr de seg ikke om. De kommer ikke til å betale deg for det.»

Dermed må du selv ta kostnaden ved å være et omstillingsbyrå. Han svarte ja. Jeg spurte om ikke det var dyrt. Han sa at det var langt dyrere å ikke lære dem hvordan de skulle gjøre det. Jeg arbeider selv i et omstillingsselskap, og det er alt vi gjør. Et digitalt byrå som prøver å ta i bruk smidig arbeidsmetodikk, må påta seg noe slikt, selv om de ikke har ekspertise på området.

Kunden som ønsket smidig arbeidsmetodikk, lærer at også de må endre seg. Det er vanskelig. Det gjør alt ti ganger vanskeligere.

Galen Low: Det er faktisk litt morsomt, for når man tenker på byråtankegangen jeg oftest møter, handler den om å hoppe på en trend og holde seg konkurransedyktig. Det er mer et markedsføringstiltak. De prøver å bruke det til å selge digital omstilling.

De sier: «Ja, vi bruker smidig arbeidsmetodikk. Vi bygger den nye digitale infrastrukturen din, nettsiden din, og kobler sammen alle kontaktpunktene mot kundene. Alle dataene dine skal samles.» Men de tenker ikke på sin egen reise mot smidig arbeidsmetodikk som digital omstilling.

Det er et middel for å levere digital omstilling til en kunde, men de tar ikke sin egen medisin. De ser det ikke engang slik. De tenker: «Dette er bare et prosess- eller driftsspørsmål. Vi endrer bare rekkefølgen på trinnene og finner ut av det underveis.»

Samtidig sier de det stikk motsatte til kunden: «Dette er endringsledelse. Vi trenger en kommunikasjonsplan, opplæring og alt dette.» Men internt gjør de ingenting av det.

Dave Prior: De påfører kundene smidig arbeidsmetodikk før de selv har tatt den i bruk. Mange selskaper som gjør dette, har egentlig ikke tatt den i bruk. Selv organisasjoner som Scrum Alliance sliter med å arbeide smidig. Det er ikke enkelt.

Galen Low: På en måte er det kanskje selve reisen. Vi havner i mange debatter. Du har sikkert vært med på mange av dem. Fossefallsmodellen versus smidig arbeidsmetodikk, prediktiv versus adaptiv, dette versus det andre. Det er mye intern strid, debatt og diskusjon.

Men selv måten du rammer inn dette som en reise på, handler mer om overgangen til en bestemt tankegang enn om å få alt perfekt. Som du sier: Selv Scrum Alliance, av alle organisasjoner, sliter fortsatt med dette.

Dave Prior: Det er på samme måte som at PMI heller ikke bruker det de lærer bort. Det er vanskelig, og det krever en svært konsekvent innsats. Noe jeg synes er forfriskende ved det digitale byråmiljøet, er at det er yngre. I min erfaring er debatten der ikke like intens som den var tidligere.

Nå har jeg generasjon Z-deltakere på kursene mine som aldri har arbeidet etter fossefallsmodellen. De vet ikke engang hva det er. De ser ikke skillet. Det finnes ingen barriere der, og det er flott, for for meg er dette bare verktøy. Noen verktøy fungerer ett sted, andre fungerer et annet sted. Jeg bruker fossefallsmodellen sammen med smidig arbeidsmetodikk, og smidig arbeidsmetodikk sammen med fossefallsmodellen.

Når vi kommer til et punkt der de bare oppfattes som verktøy, og folk kan velge de riktige verktøyene til riktig jobb på riktig sted, vil vi være i en mye bedre situasjon.

Galen Low: Det liker jeg. Jeg ville faktisk gå litt dypere inn i det, for det treffer meg veldig i byråverdenen.

Det finnes yngre fagfolk i disse bransjene. De kjenner smidig arbeidsmetodikk, ønsker å bruke den og har kanskje ikke engang erfaring med fossefallsmodellen. Likevel ser jeg fortsatt mye stigma rundt det å ikke være «ren» smidig. «Wagile» og «Watergile» blir nærmest skjellsord i byråverdenen.

Samtidig ser jeg at hybride tilnærminger og tilpasning av metoden blir stadig vanligere. Men i denne boblen av byråverdenen føles det fortsatt uakseptabelt å ha litt fossefallsmetodikk i den smidige tilnærmingen og litt smidig arbeidsmetodikk i fossefallsmodellen.

Dave Prior: Folk henger seg veldig opp i dette, og jeg synes det er uheldig. Ingen bryr seg. Det er ikke slik at Scrum-politiet kommer og arresterer deg. Du må velge de riktige verktøyene. Når folk spør om de gjør det riktig, svarer jeg ja. Jeg bryr meg ikke om hva du gjør. Du gjør det riktig. Den eneste måten du virkelig kan gjøre dette feil på, er å ikke ha tilbakeblikk.

Jeg hadde en samtale i går med to team som sa at de arbeidet smidig, men de gjennomførte verken sprintgjennomganger eller tilbakeblikk. Tilbakeblikket er viktigere enn arbeidet du produserer, for selv om du ikke lykkes med leveransen, er tilbakeblikket stedet der du finner ut hvordan du kan unngå det neste gang.

Hvis jeg kunne formidle to budskap, ville det første være at ingen bryr seg om du arbeider etter en ren fossefallsmodell eller en ren smidig modell. Det andre er at du må gjennomføre tilbakeblikk, ikke bare på slutten av prosjektet, men på slutten av hver eneste sprint.

Galen Low: Nettopp. Og det er fordelen når man ser på fordeler og ulemper ved en prediktiv versus en adaptiv tilnærming. En av de sterkeste fordelene er at vi får reflektert over arbeidet tidligere.

Man kan selvsagt ha et fossefallsprosjekt med periodiske tilbakeblikk, bedre risikostyring eller forhåndsvurderinger, men tankegangen om å samarbeide, reflektere og lære er innebygd i verdiene og prinsippene for smidig arbeidsmetodikk. Man fortsetter å iterere og øke leveransene mot målet.

Dave Prior: Jeg tror læring er det viktigste. Det er derfor det blir så stressende når folk sier at de trenger mer presise estimater. Hvis de var presise, ville de ikke blitt kalt estimater. Du har ikke nok informasjon til å gjette noe som kommer til å være helt riktig.

Du gjør så godt du kan, og prøver stadig å komme nærmere det du må levere for at kunden skal få verdien sin, og for at teamet skal få verdi av å arbeide sammen. Det er også svært viktig.

Galen Low: Jeg antar at det er her man treffer den største innvendingen i en byråkontekst mot at smidig arbeidsmetodikk kanskje ikke fungerer. De sier: «Vi skal gjøre vårt beste», og hvis du sier det til en kunde, svarer de: «Vent litt. Jeg betaler så mye per sprint, og dere skal bare gjøre deres beste?»

Dave Prior: Jeg tror det handler om hvordan du skriver arbeidsbeskrivelsen. Da jeg begynte, for lenge siden, hadde vi arbeidsbeskrivelser som innebar at vi arbeidet i et år, leverte til kunden, og fikk høre: «Jeg er ikke fornøyd.» Det betydde at jeg arbeidet gratis i en måned til kunden var fornøyd. Dermed fikk vi mer arbeid som kunden heller ikke ville bli fornøyd med.

Jeg begynte å skrive arbeidsbeskrivelsene mine slik at jeg satte meg ned med kunden og sa: «Det er 12 ting jeg skal levere til deg ifølge denne arbeidsbeskrivelsen. Sørg for at alt du trenger, står her. Når jeg leverer disse 12 tingene, vil jeg ikke høre at du ikke er fornøyd. Jeg vil høre: Her er sjekken din.»

Nå skriver jeg arbeidsbeskrivelser på en helt annen måte. Jeg skriver: «Min forståelse av det du ønsker, er X. Basert på samtalene våre finnes det kanskje noen overordnede spørsmål knyttet til omfanget. Med denne forståelsen tror vi at det vil kreve så mange personer, så lang tid og så mye penger.»

Det er et smidig prosjekt, så vi arbeider etter prioriteringene kunden setter. Arbeidsbeskrivelsen sier i praksis: «Jeg kommer hjem til deg med seks personer. Vi klipper plener, lager kaker, skriver programvare eller gjør hva du nå ønsker. Men taksameteret går, og det er ditt ansvar å sørge for at du får det du trenger.»

Hvis kunden ber deg redesigne banneret 75 ganger, kan du gjøre det, men da får de ikke de andre tingene de ønsker. Det er deres valg. Derfor er dette en viktig samtale å ta på forhånd. Kunden må være villig til å ta ansvar for at de selv navigerer i hva som skal gjøres.

Galen Low: Jeg tror lytterne mine tenker: «Hvis jeg skrev en slik arbeidsbeskrivelse i byrået mitt og sendte den oppover, ville sjefen min eller ledelsen sagt: Hva er dette? Nei, den må være mer detaljert.»

Dave Prior: Det er et forretningsvalg. Når arbeidsbeskrivelsen er mer detaljert, må du ta hensyn til at kunden som ønsker den, kanskje ikke engang vet hva som er galt. De har bestemt seg for at de vil ha en bestemt ting, og når du bygger den, sier de: «Dette er egentlig ikke det vi trenger.» Da finnes det ingen fleksibilitet.

Det er avveiningen. Kunden kan få et produkt på slutten som dekker behovene deres, hvis de er villige til å forplikte seg til tiden og samarbeidet. Det finnes usikkerhet uansett, men vi erkjenner den på forhånd. Det krever kanskje litt mer mot.

Galen Low: Mot er et godt ord. Jeg liker også hvordan du bruker arbeidsbeskrivelsen som en mulighet til å bevise at du forstår problemet.

Du vet kanskje ikke løsningen ennå, men du begynner med: «Min forståelse er dette.» Jeg tror det grunnleggende er noe av det som er ødelagt i forholdet mellom byrå og kunde. Det blir: «Teamet ditt skal utføre kravene mine.»

I stedet burde det være: «Jeg stoler på at du forstår forretningsproblemet jeg prøver å løse, og jeg trenger kloke mennesker som kan iterere sammen med meg for å finne løsningen.»

Dave Prior: Det går helt tilbake til manifestet for smidig arbeidsmetodikk: kundesamarbeid fremfor kontraktsforhandling. Jeg pleide å behandle kontraktene mine som et skjold som skulle beskytte meg mot de dumme kundene mine. Nå ser jeg på dem som noe som skaper scenen for samarbeid.

De vet ikke hva de trenger, og jeg vet ikke hvordan jeg skal gi dem det, men vi skal samarbeide. De må gå inn i dette med åpne øyne. De må vite at det vil stilles større krav til dem, og at de må være mer engasjerte, men vi finner ut av det sammen.

Galen Low: Det snur nesten maktforholdet. Byrået sier: «Du må fortsatt fortelle oss hva vi skal gjøre. Vi gir deg informasjon om hvor lang tid ting tar og hvilken kapasitet vi har, men sprint for sprint …» Kunden sier: «En del av grunnen til at jeg hyret et byrå, var at jeg skulle ha noen å skylde på. Nå sier du at dette faktisk er mitt ansvar.»

Dave Prior: Når folk begynte å ta inn klausuler om pauser i arbeidsbeskrivelsene, sto det for eksempel at kunden måtte gi tilbakemelding innen to dager. Hvis ikke, ville teamet bli omdisponert. Det er fortsatt en ganske straffende måte å håndtere det på.

Jeg mener at man må kunne sette seg ned med kunden på forhånd og si: «Du må være sammen med oss hver dag. Hvis du vil at dette skal fungere, og hvis du vil at vi skal arbeide smidig, er dette det som kreves.» Hvis du er et byrå som prøver å selge smidig arbeidsmetodikk til kunden, handler det ikke bare om å si: «Har du hørt det gode budskapet?» Det handler også om å si: «Har du hørt det gode budskapet, og vet du at jeg kommer til å bruke halvparten av tiden din?»

Hvorfor betaler de deg for å bruke mer av tiden deres? Det går tilbake til spørsmålet om hvilket problem dette løser.

Galen Low: La oss stoppe ved det spørsmålet. Hvilket problem løser dette for kunden? I dette scenarioet må kunden bruke mer tid og like mye penger på å få noe som forhåpentligvis blir riktig løsning på problemet, men jeg kan ikke gå til hvem som helst og si: «Vi har et byrå som skal bygge denne løsningen.»

Dave Prior: Du kan si at dere skal løse et problem. En stor del av dette handler om å bli glad i problemet. Den gamle måten var at man pekte på en ting og bare gikk dit, uansett hva som skjedde ellers: pandemi, markedsendringer og så videre.

Dette handler om å ta ett skritt, stoppe, se seg rundt og spørre: «Skal vi fortsette denne veien, eller skal vi snu?» Det er i praksis det samme som i en slank oppstartsbedrift. Vi vil gi kunden muligheten til å lære og justere, og vi lærer og justerer sammen med dem.

For at det skal fungere, må man arbeide sammen, undersøke og tilpasse underveis. Det er én ting å si at man vil ta en medisinsk grad. Det er noe annet å si at man skal ta en medisinsk grad ved Harvard med et bestemt karaktersnitt. Hva om du ikke kommer inn på Harvard? Da er du fortapt, men du kan fortsatt ta en medisinsk grad. Eller kanskje du innser at du ikke vil bli lege, men veterinær. Vi vil gi dem muligheten til å lære og endre retning, men det har en kostnad.

Galen Low: Jeg liker virkelig denne ideen om samarbeid. Det er samarbeidet og tilliten som får det til å fungere. Og jeg går tilbake til det du sa innledningsvis: Noen ganger må man se det fungere for å kunne stole på det.

Dave Prior: Jeg kjenner ingen som virkelig har sluttet seg til dette før de har sett det fungere.

Galen Low: Dermed handler «kontraktsforhandlingen» mindre om å beskytte seg mot dumme kunder og urimelige krav, og mer om å få kunden gjennom den første sprinten, slik at de kan se det i praksis. Deretter blir det enklere og enklere fordi tilliten bygges sprint for sprint og iterasjon for iterasjon.

Dave Prior: Når det gjelder risiko, ville vi i et selskap med en ny kunde kanskje bare tatt arbeidet for et kvartal i stedet for to år. Hvis teamet mitt var det eneste teamet kunden hadde arbeidet med, leverte annenhver uke og lot kunden se og ta på konkrete ting og gi tilbakemelding, var det aldri noe problem å få mer penger.

De er ikke vant til å se en slik gjennomføringstakt, og de blir imponert. Det er noe de begynner å sette pris på, og dermed blir de mer villige til å gi etter for arbeidsmåten.

For teammedlemmene kan det være frustrerende å gjøre ting på nytt. Designere og utviklere hater å måtte gjøre noe to ganger. Men når de ser resultatet for kunden og sluttbrukeren, og ser hvor mye bedre det blir fordi man faktisk viste det frem flere ganger, underbygger det alltid saken.

Galen Low: Jeg liker dette med å se beviset i resultatet. Men det skaper selvsagt en situasjon der man må si: «Stol på oss, la oss prøve. Når du har opplevd det, kommer det til å bli bra.»

Dave Prior: Jeg ville sagt: «Stol på oss.» Vi skal jo arbeide sammen. Hvis noen ikke får det de trenger, er det begge parters feil. Men begge må være villige til å gå inn i denne ordningen.

Galen Low: Det er rimelig. Jeg vil gå tilbake til to ting du sa tidligere. Den ene var at man kanskje må takke nei til arbeid, noe mange byråer kan være allergiske mot.

Dave Prior: Ikke økonomisk allergiske. De kan ikke det. De må ta hvert eneste oppdrag.

Galen Low: Greit nok. Den andre tingen var at investeringen i å lære opp en kunde i smidig arbeidsmetodikk faktisk kan hjelpe deg med å tjene mer penger, i stedet for å tape en hel masse.

Det kan være en investering som lønner seg. Mange i fellesskapet vårt sliter med dette. De har overbevist folk om å bli med på et smidig prosjekt. Alt høres bra ut. Så sier de: «Nå er du produkteier.» Og kunden svarer: «Hva innebærer den jobben?»

Dave Prior: Nettopp.

Galen Low: Og de leverer ikke etter forventningene. Det finnes ikke noe budsjett til opplæring, og de lærer på den harde måten underveis. Noen sa en gang til meg: «Ingen lærer en kunde å være kunde.» Jeg har aldri glemt det. Spørsmålet er: Hvorfor ikke?

Dave Prior: Det burde de. Man må kanskje lære folk å være gode kunder.

Galen Low: Du nevnte noen byråer som hadde organisert seg rundt smidig arbeidsmetodikk. Sender noen av dem kundene sine til deg for opplæring?

Dave Prior: Ja, det skjer ofte. Mange fra byråer kommer til meg, og mange av byråkundenes kunder blir sendt på kurs, fordi dette er svært vanskelig. Selv om byrået tar ansvar for å veilede og lære opp kunden, er ikke dette nødvendigvis kjernekompetansen deres.

Jeg har undervist i prosjektledelse og smidig arbeidsmetodikk i over 20 år. De jeg kjenner som har veiledet like lenge, har dette som jobb. Det er alt de gjør. De studerer det som et fag. Hvis det mer er en hobby eller noe du må gjøre, vil du kanskje ikke ha nok erfaring til å få den virkningen du ønsker.

Jeg sier ikke at alle byråer bør ansette opplærere, men det er en risiko man må erkjenne. Du forstår noe bare delvis, og likevel veileder og lærer du det bort til andre. Det er greit, men da lærer dere sammen, og dere må akseptere at det følger risiko, feil, misforståelser og alt annet med.

Galen Low: Det bør også inngå i den innledende kontrakten. Slik jeg ser historien, sier byråene: «Vi er eksperter på smidig arbeidsmetodikk, og kanskje vi kan lære deg dette.»

Dave Prior: De tok et todagerskurs med meg, og nå er de eksperter. Ja, det er det som skjer.

Galen Low: Og alt kommer til å gå perfekt. Det er ikke å håndtere forventningene til teamet, kunden eller byrået, for dette handler egentlig om læring. Ting kommer kanskje ikke til å gå så smidig. Hvis idealet ditt er at alt skal gå perfekt og ingen problemer noen gang oppstår, kommer du sannsynligvis ikke til å nå det.

Dave Prior: Det ville vært som om jeg leste en bok om hvordan man flyr fly, så noen YouTube-videoer og deretter lærte deg å fly. Det krever mye erfaring og mange feil for å bli god på dette.

En annen utfordring er at mange byråer har kortvarige kundeforhold. De bygger apper, kampanjer eller andre kortvarige leveranser. Hvis kunden er på løpende avtale, kan det passe bedre for denne typen arbeid, fordi man vet at forholdet er langsiktig. Da kan man si: «La oss prøve dette.» Kanskje Scrum fungerer, kanskje ikke.

Et problem med Scrum i et byrå er toukersmodellen, reglene og lignende. Kanskje Kanban passer bedre. Men byråer som ikke får Scrum til å fungere, og som ønsker å gå over til en skaleringsmodell, bør tenke seg om. Skalering er ikke problemet deres.

Galen Low: Ja, la oss gjøre problemet enda større.

Dave Prior: «Jeg kan ikke krype. Hvor er motorsykkelen?»

Galen Low: Utmerket. Jeg tror det samme ofte gjelder prosjektteam. I byråer blir ressursene fordelt slik at enkelte bytter team fra sprint til sprint.

Det teamet lærer ikke sammen, fordi medlemmene hele tiden flyttes rundt fra prosjekt til prosjekt, der de passer inn, uten nødvendigvis å få lære sammen som et team. Møter du mange situasjoner der byråer sier: «Nei, nå bruker vi bare dedikerte team»?

Dave Prior: Det finnes noen alternativer. Mange organisasjoner går fra å være prosjektorienterte til å bli produktorienterte og finansierer team. Min anbefaling til byråer er at hvis de ikke skal satse fullt på Scrum eller noe lignende, kan teamene kanskje måtte arbeide med flere prosjekter samtidig.

Det kan være virkeligheten i virksomheten. Men kan dere finansiere stabile team? Hvis jeg har et stabilt team som arbeider med sju ulike prosjekter, kan de i det minste ha én arbeidskø og utvikle kommunikasjonsmønstre og bli høytytende. Hvis dere ikke kan gjøre det, tror jeg ikke Scrum kommer til å fungere.

Da ville jeg brukt en fossefallsmodell, en smidig modell, en hybrid eller hva dere nå ønsker. Dere trenger heller ikke gå helt inn i Scrum. Dere kan ta enkelte elementer. Dere kommer kanskje ikke til å bruke Scrum slik Ken Schwaber ville godkjent, men hvem bryr seg?

Det er bare verktøy. Bruk dem til deres fordel. Hvis det hjelper å ha et daglig Scrum-møte, så ha et daglig Scrum-møte. Men ikke ha det i Slack; ha det ansikt til ansikt, som en samtale i sanntid.

Mange steder hopper imidlertid over praksiser uten å prøve dem først. De sier bare: «Vi skal ikke ha en sprintgjennomgang.» Eller: «Sprintgjennomgangen vår er når dette teamet viser arbeidet til det andre teamet.» Det er ikke en sprintgjennomgang. Prøv tingene disiplinert først, og finn ut hva som fungerer og ikke fungerer. Gjør deretter endringer.

Galen Low: Test det. Det fungerer kanskje ikke for organisasjonen deres. Det er greit om dere ikke bruker hundre prosent av alt.

Dave Prior: Hvis det ikke fungerer, er det greit. Dere testet det, og det fungerte ikke. Gjør noe annet.

Galen Low: Og dere lærte, ikke sant? Tilbake til poenget ditt om at dette handler om læring. Det liker jeg.

Dave Prior: For et byrå handler dette også om å skape et miljø der folk hele tiden lærer og utvikler seg i rollen, ferdighetene og faget sitt. Da blir de værende og tåler mye bryderi. Hvis du gir dem et miljø der de ikke kan gjøre det, og ber dem følge en prosess de ikke kan bruke fordi organisasjonsstrukturen hindrer det, blir de ikke værende.

Galen Low: Der traff du spikeren på hodet. Dette handler ikke om å ha en perfekt prosess, et perfekt rammeverk eller en perfekt metode som alle skal slutte seg til og følge. Det viktige er at de slutter seg til noe og følger det. Det handler om tillit, samarbeid og om å lære sammen.

Alle detaljene om hvorvidt man har innarbeidet én bestemt idé, klausul eller modell i tilnærmingen, er mindre viktige. Det viktige er om vi blir bedre til å levere arbeid.

Dave Prior: Hvis jeg er kunde, og valget står mellom et byrå som gir meg en svært detaljert og spesifikk arbeidsbeskrivelse som går som en saltgruve, eller et sted der de sier: «Ja, vi tror det er dette, men …», mens jeg ser at menneskene som arbeider der er engasjerte og lidenskapelige, velger jeg de menneskene.

De kommer til å engasjere seg like mye som meg, og vi finner ut av det sammen. På Frederick Taylors tid fungerte saltgruvemodellen i en fabrikk der man bygde maskindeler. Men det er ikke det vi gjør. Dette er kunnskapsarbeid. Det er helt annerledes.

Galen Low: Det er absolutt et annet arbeid. Jeg liker ideen om at det grunnleggende handler om lidenskap, som du sier. Mennesker som brenner for arbeidet og forstår det. Jeg ville også valgt det. Det må bygges inn i modellen.

Selv med bakgrunn fra forretningsutvikling ser jeg at dette er et mye bedre salgsargument enn: «Vi følger smidig arbeidsmetodikk etter boken. Alle er sertifisert, og vi følger alt til punkt og prikke.» Det motsatte er faktisk det som gjør det overbevisende.

Det overbevisende er å si: «Vi skal gå inn i problemet sammen fordi vi bryr oss om det. Vi liker dette, vi er flinke til det vi gjør, og vi skal arbeide med det sammen. Det kommer til å bli bra. Nå har du et team, ikke bare en gruppe mennesker som kommer med unnskyldninger.»

Dave Prior: Og vi skal støtte hverandre og hjelpe hverandre med å vokse sammen.

Galen Low: Jeg liker det. Jeg vil gå tilbake til én ting: fart. Vi har snakket om byråmodellen, om hvordan den kan omstruktureres for å få en mer smidig kultur, og om hvordan man får folk med. Vi har snakket om å lære opp kunder, men det finnes organisasjoner der kundene ikke klarer å holde tritt.

Vi snakker om toukerssprintene i Scrum, daglige møter og at kunden må være involvert og ta beslutninger underveis. Kunden forventes å kunne ta en nøyaktig beslutning i et møte i stedet for å sende den oppover i systemet, der det kanskje tar tre–fire uker.

Hvordan kan byråer hjelpe kundene med å arbeide i dette tempoet, eller vurdere muligheter slik at de bare tar kunder som oppfyller bestemte kriterier og kan holde tritt?

Dave Prior: Kanskje kan de det. Jeg ville snakket med kundene og fått dem til å bli enige om alt dette på forhånd. Men hvis du finner ut at de ikke klarer det, bør du ikke behandle det som om de er dårlige eller har gjort noe galt. Spør heller hvorfor.

Kanskje forventningen var urealistisk. Hva ville vært realistisk? I hver sprint finnes det to eksperimenter: Hvordan leverer vi verdi til kunden, og hvordan lærer vi å arbeide bedre sammen som team? Kunden er en del av teamet. Hvis de ikke kan snu ting så raskt, eller må få godkjenning fra et annet nivå, er det greit. Hva kan vi gjøre med det?

De arbeider kanskje i en organisasjon som heller ikke er smidig, og må gå gjennom de samme hindrene som dere. Hvis dere vet det, kan dere gjøre tilpasninger.

Galen Low: Det jeg tar med meg, er spørsmålet: Gjør vi smidig arbeidsmetodikk riktig? Ja.

Dave Prior: Dere gjør det alle riktig. Så lenge dere har tilbakeblikk og ikke prøver å ha det daglige Scrum-møtet i Slack, gjør dere det riktig.

Galen Low: Jeg avslutter med et uventet spørsmål. Vi har snakket om at dette er verktøy. Smidig arbeidsmetodikk er et verktøy. I noen prosjekter fungerer det kanskje ikke. I noen organisasjoner fungerer det kanskje ikke.

Samtidig snakker vi om at hele organisasjonskulturen noen ganger må endres. En organisasjon kan måtte gjøre omfattende endringer. På kundesiden må kulturen kanskje også bli mer fleksibel og smidig, eller så må vi tilpasse oss den.

Handler dette bare om at alle skal bli mer smidige, både organisasjonene og kulturen deres? Eller finnes det fortsatt plass til å si: «I dette tilfellet velger jeg fossefallsverktøyet»? Skaper det en konflikt med en smidig kultur å ha to hammere, én smidig og én basert på fossefallsmodellen, og bruke begge etter behov?

Dave Prior: Jeg vil si at det å forsøke å ha en smidig kultur nesten er en feilslutning. Jeg ville heller arbeidet for en menneskelig kultur som lar folk trives og levere verdi sammen.

Når jeg arbeider med smidige prosjekter, bruker jeg et tradisjonelt risikoregister på alle prosjektene mine, fordi det er et nyttig verktøy for interessenter som kan tømme ut bekymringene sine der, og som jeg kan vise dem.

En del av det å være en god prosjektleder er å tilpasse seg publikum. Hvis kundene dine bare kjenner fossefallsmodellen, må du ikke presse frem en bunke burndown-diagrammer som de ikke vet hvordan de skal bruke. Du tar i bruk de verktøyene du trenger fra den praksisen du trenger for å levere verdi til kunden.

Hvis målet er et menneskelig miljø som leverer verdi til kunden, bør du la det være veiledende. Ikke bekymre deg for om alt er smidig nok. Ingen blir noen gang smidig nok. I det øyeblikket du sier «Jeg er smidig», er du ferdig. Det øyeblikket du sier det, slutter du å være smidig.

Selv menneskene som skapte dette, finner fortsatt ut av det. Det er det vakre ved det. Det er en ufullkommen og uferdig modell som vi alle får bidra til. Du kan påvirke endring. Jeg er sikker på at det finnes mennesker i byråer nå som vil endre måten byråer tar i bruk smidig arbeidsmetodikk på. I den beste av alle verdener vil det oppstå en versjon som er tilpasset digitale byråer.

Galen Low: Jeg liker dette veldig godt, og skulle ønske flere sa det. Det var forfriskende å høre: Hold det menneskelig. Hva handler egentlig alt dette om? Det handler ikke om å bruke hvert eneste verktøy i verktøykassen.

Dave Prior: Jeg gjorde akkurat det. Jeg tok PMP-sertifiseringen og innførte PMBOK fra begynnelse til slutt. I ett selskap varte det i tre uker, og det tok to år å gjenopprette troverdigheten min.

Galen Low: Oi. Greit.

Dave Prior: Alle sa: «Glem det. Vi skal ikke fylle ut alle disse dumme skjemaene.» Det er også en verktøykasse. Du skal ikke bruke alt i PMBOK.

Galen Low: Nettopp. Det samme gjelder smidig arbeidsmetodikk, og det bør være greit. Prosjektlederens rolle blir da å organisere samarbeidet: Hvordan kan vi få gjort godt arbeid, levere verdi til kunden, lære av hverandre underveis og bli bedre på det?

De verktøyene som fungerer for dette, er de vi bør bruke. Hvis de ikke fungerer, slutter vi å bruke dem.

Dave Prior: Nettopp.

Galen Low: Dette er utrolig forfriskende å høre, både for meg og forhåpentligvis for lytterne. Jeg vet at dette er en stor utfordring.

Dave Prior: Det finnes en bok som heter «The Collaboration Equation» av Jim Benson, med mye godt om å skape en menneskelig arbeidsplass. Han oppfant Personal Kanban, sammen med Tonianne DeMaria, og Lean Coffee sammen med Jeremy Lightsmith. Det er mye bra der.

Galen Low: Veldig interessant. Jeg skal sjekke den ut, og legger lenken i programnotatene, slik at folk kan følge den. Selv titlene høres spennende ut.

Dave Prior: Det er en veldig god bok.

Galen Low: Dave, tusen takk for at du var sammen med oss i dag. Det har vært en stor ære å ha deg med. Hvis folk vil lære mer om det du gjør, hvordan kan de finne ut mer?

Dave Prior: De kan gå til drunkenpmradio.com. Jeg har en podkast der. De kan også gå til LeadingAgile, der jeg er tilgjengelig. LinkedIn er sannsynligvis den enkleste måten å finne meg på, siden jeg ikke bruker de andre sosiale mediene særlig mye lenger.

Galen Low: Ja, det er ganske urolig der nå. LinkedIn er den stabile plattformen. Jeg inkluderer alle lenkene i programnotatene. Takk igjen.

Dave Prior: Og takk for at du inviterte meg. Dette var veldig morsomt. Jeg blir nesten aldri intervjuet, så dette var kjempegøy.

Galen Low: Der har du det. Vi inviterer deg kanskje tilbake. Dette er et så dypt tema, og jeg vet at lytterne kommer til å ha flere spørsmål etter hvert som de hører på. Vi vil gjerne ha deg tilbake.

Da har dere det, alle sammen. Som alltid: Hvis du vil delta i samtalen med over 1 000 likesinnede forkjempere for prosjektledelse, kan du bli med i fellesskapet vårt. Gå til thedigitalprojectmanager.com/membership for å lære mer. Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com.

Til neste gang: Takk for at du lyttet!