Måle travelhet kontra å måle resultater

 

Les transkripsjonen:

Vi prøver ut å transkribere podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, ettersom boten ikke har 100 % rett hele tiden.

Galen Low: En liten quiz: Du er halvveis i prosjektet, og alle målene dine ser gode ut. Leverandøren har brukt det avtalte antallet timer, og teamets hastighet og utnyttelsesgrad er akkurat der du planla at de skulle være.

Men til tross for at prosjektet ditt ser friskt og sunt ut, bommer produktet stadig på målet i fokusgrupper og brukertester. Teknologien som den utøvende sponsoren din var fast bestemt på å bruke, blir raskt utdatert, noe som gjør det vanskelig å gjennomføre endringer. Og moralen i teamet er lav: Når du ber dem om løsninger, trekker de på skuldrene og sier at de gjorde det de ble bedt om, innenfor den tildelte tiden.

Så hvordan kan prosjektet ditt være sunt selv om resultatet ikke skaper den tiltenkte verdien?

Hvis du opplever at prosjektmålingene dine måler travelhet mer enn verdi, bør du lytte videre. Vi skal se nærmere på den praktiske mekanikken i hvordan prosjektteam kan måle verdi, og utforske ideer for å flytte insentivet fra brukte timer til skapt verdi.

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

I dag snakker vi om forskjellen mellom å måle prosjektets helse og fremdrift, og å måle prosjektets suksess. Er det nok å følge med på teamets hastighet og kostnadsresultater? Eller er det også vårt ansvar som prosjektledere å måle prosjektets resultater og påvirkning?

Med meg i dag har jeg Fred Fowler – en nivå 3-sertifisert Scrum-master som har utgitt flere bøker om Scrum-metodikken, organiserer Silicon Valley Professional Scrum-møtegruppen med rundt 2 000 medlemmer, leder et tilsvarende Scrum-fellesskap i Shanghai i Kina og organiserte den første Silicon Valley Scrummit-konferansen. Med andre ord: En person som kan en ting eller to om Scrum.

Velkommen, Fred!

Fred Fowler: Hei! Takk for at jeg fikk være med i programmet.

Galen Low: Hyggelig å ha deg her.

Fred Fowler: Jeg presenterer meg som en Scrum-fyr. Selv om noen kanskje vil si at jeg er «scrumtastisk».

Galen Low: Det er bedre enn at jeg skulle kalle Fred for «Scrum-jordens salt».

Fred Fowler: Det finnes alle mulige måter å leke med ordet Scrum på. Man kan være en Scrum-bag og så videre. Uansett, bare fortsett.

Galen Low: Nettopp. Fantastisk. Du har en så interessant bakgrunn, og jeg tror den vil gi lytterne våre mye kontekst for hvordan du ser på prosjektmålinger. Hvis jeg har forstått det riktig, begynte du som programmerer, gikk deretter over til politikk, ble ordfører og endte som IT-direktør før du begynte å bruke den sjeldne nivå 3-sertifiseringen som Scrum-master til å hjelpe andre.

Kan du fortelle litt om reisen din, og hvordan erfaringene dine har formet måten du ser på ting i dag?

Fred Fowler: Jeg vil si at karrieren min har vært som å befinne seg i en flipperspillmaskin.

Jeg begynte som programmerer i 1980. Du vet, i oldtiden, da jeg jobbet på en maskin som var så stor og tung at det i praksis krevde spesialutstyr å flytte den, og som var mindre kraftig enn en vanlig telefon i dag – smarttelefonen din. Men vi drev en avdeling i et halvlederselskap ved hjelp av den, og der lærte jeg ferdighetene mine.

Jeg gikk videre, for dette var Silicon Valley i de tidlige årene, noe som innebar stor ustabilitet. I løpet av de første åtte årene av karrieren jobbet jeg for fem forskjellige selskaper. Til slutt tenkte jeg at jeg trengte jobbsikkerhet, så jeg burde jobbe for meg selv.

Jeg ble konsulent og jobbet for 60 forskjellige selskaper de neste ti årene. Jeg gjorde stort sett det samme hele tiden: forsøkte å bruke teknologi til å løse forretningsproblemer, som egentlig er det alt handler om. Deretter var det et selskap jeg jobbet for som konsulent.

De ga meg et tilbud jeg ikke kunne avslå. Jeg endte med å lede IT-driften deres og ble, som jeg sier, IT-direktør. Jeg innførte mange teknikker som i praksis viste seg å være Scrum-teknikker, selv om jeg ikke innså det på den tiden. Jeg ga folk myndighet til å løse problemer og begrunnet arbeidet ut fra avkastningen på investeringen.

På den tiden gjennomførte jeg mange prosjekter som formet hele synet mitt på hvordan man organiserer virksomhet. Mange av dem er jeg stolt av. Selskapet hadde brukt mye tid på å bygge et nettsted ved hjelp av et stort, kjent datateknologiselskap.

De betalte en kvart million dollar for en ganske elendig netthandelsløsning. Jeg ble involvert og så store muligheter for forbedring. Jeg organiserte et prosjekt og satte opp lange Scrum-linjer.

Vi hadde to forskjellige teknologier involvert. Det fantes en eldre IBM-minidatamaskin, en AS/400, som fungerte som bakende, men vi trengte en forside. Jeg reiste til Kina og fant et lite, ambisiøst selskap som kunne lage forsiden. Det amerikanske teamet bygde bakenden, det kinesiske teamet bygde forsiden, og det eneste vi måtte finne ut av, var hvordan plattformene skulle kommunisere med hverandre.

Det viste seg å være ganske enkelt. Vi erstattet et arbeid til en kvart million dollar med et nettsted som etter seks måneder sto for 40 prosent av selskapets virksomhet, og som kostet 14 000 dollar å lage. Det var enkelt: Finn mennesker som forstår teknologien, gi dem et problem å løse, og la dem løse det.

Galen Low: Der har du det. Smidige team, datakontrakt, og så er det bare å sette i gang.

Fred Fowler: Nettopp. Det som virkelig var avgjørende, var å forstå hva som var viktig å måle.

Når man snakker om team i andre land, får alle panikk og spør hvordan vi skal vite hva de gjør. Derfor vil vi ha alle mulige verktøy for å måle hvor hardt de arbeider og hvor travle de er. Vi vil at de skal være travle hele tiden.

Men vet du hva? Det spiller ingen rolle. Det er ikke viktig om folkene i utlandet er travle eller ikke. Det viktige er hva de faktisk leverer, og hvilken verdi leveransen har. Det er dette du bør måle. Glem å holde stoppeklokker mot folk.

Tenk deg et team på over 200 personer som arbeider åtte eller ti timer om dagen i to år, sammenlignet med et team på fem, seks eller ti personer som arbeider vanlig arbeidstid i ett år. Hvem tror du ville levert mest verdi? Det viste seg at de 200 personene som arbeidet i to år, skapte det som kalles healthcare.gov, et nettsted som ble en total katastrofe.

Det skulle være et system for å gjennomføre Obamas helsereform. Det krasjet og brøt sammen fordi de 200 personene ble målt på hvor travle de var. De ti personene det neste året skrev hele løsningen på nytt og fikk den til å fungere. De leverte langt mer verdi enn de 200 andre.

Galen Low: La oss gå dypere inn i dette. Jeg tror det er et veldig viktig poeng. Du nevnte en av grunnene til at vi måler travelhet, men i min verden kommer jeg fra byråer og konsulentselskaper, og alt handler om fakturerbare timer, utnyttelsesgrad, hvor mange feil vi har rettet eller hvor mange oppgaver vi har fullført.

Hvorfor har vi denne tendensen til å måle travelhet?

Fred Fowler: Det er enkelt: Det er lett å måle. Alt du trenger for å måle hvor travle folk er, er en klokke. Alt du trenger for å finne ut om folk holder en rekke tidsfrister, er en kalender. Det er lett å måle, og det danner grunnlaget for kompensasjon.

Du nevnte fakturerbare timer. Det er en stor misforståelse å tro at tiden til folk er det verdifulle. Tiden deres er verdifull for dem, men det som er verdifullt for deg, er hva de gjør med tiden. Det ville vært mye bedre om verden hadde en god målestokk for å måle resultatene av folks tid.

Når jeg snakker med selskaper, sier jeg at de først og fremst må finne ut hvilken verdi de ønsker å skape, dele den opp i meningsfulle og målbare deler, og deretter måle fremdrift basert på den skapte verdien. I smidig utvikling finnes ideen om et minimum levedyktig produkt.

Man lager så mye av produktet som er nødvendig for å få noe i hendene på kunden. Hvorfor er det en god idé? Fordi noe som er i hendene på en kunde, har verdi. Kunden kan fortelle deg hvor verdifullt det er. På den måten kan du vurdere om verdien som ble skapt, var verdt kostnaden.

Hvis du har en app som koster en halv million dollar å bygge, er det da en god investering? Det kommer an på om appen legges ut på iTunes og lastes ned tre millioner ganger til to dollar per eksemplar. Da har du tjent seks millioner dollar på en investering på en halv million.

Men hvis den samme appen bare blir lastet ned 25 000 ganger til to dollar, har du brukt 500 000 dollar på å skape 50 000 dollar i verdi. Samme innsats og samme antall fakturerbare timer, men resultatet har en annen verdi. Det er resultatets verdi som betyr noe.

Galen Low: Du var inne på noe viktig om det minimum levedyktige produktet. Noen ganger måler vi travelhet fordi det handler om tillit. Vi stoler ikke på at folk faktisk gjør arbeidet, men hvis vi kan holde en klokke mot dem mens de arbeider, vet vi i det minste at de har jobbet disse timene.

Men det måler ikke verdi. Folk sier gjerne at vi selvfølgelig trenger fakturerbare timer, for det står i kontrakten og er grunnlaget for kompensasjonen. Det jeg liker med poenget ditt om det minimum levedyktige produktet, er at vi får noe ut i verden, gjør en investering, og lar kunden avgjøre om det er verdifullt.

Fred Fowler: På noen måter er fakturerbare timer et nødvendig onde. Men du må fortsatt holde folk på rett kurs ved å sammenligne kostnaden deres med verdien av resultatet. I Scrum-rammeverket må du alltid skape noe som er ferdig og klart til å gis til kunden ved slutten av hver sprint.

Hvorfor tror du det er slik? Hvorfor er det viktig at noe er ferdig, klart og kan gis til en kunde? Fordi det er den eneste gangen noe har verdi: når det er ferdig og klart til å gis til kunden.

Slik måler du verdi. Du måler verdi etter hvor mye en kunde vil betale for noe. I Scrum skaper du noe av verdi annenhver uke, slik at du kan måle verdien og sammenligne den med kostnaden ved å skape den. Du må kunne dele arbeidet opp i deler som hver har målbar verdi.

Scrum legger vekt på at beslutninger skal baseres på det du måler, ikke på gjetninger eller meninger. Det viktigste å måle er verdi.

Galen Low: Hvem vurderer om noe er verdifullt fra sprint til sprint, og hvordan følger man opp dette?

Fred Fowler: I Scrum-rammeverket er målingen av verdi i praksis én persons ansvar. Scrum deler ansvaret i tre deler: produkteieren, utviklerne og Scrum-masteren.

Produkteierens jobb er å maksimere verdien av teamets arbeid. Produkteieren er ansvarlig for verdien. Du kan ikke maksimere noe uten å kunne måle det, for hvis du ikke kan måle det du forsøker å maksimere, vet du ikke om det du gjør, gjør det bedre eller verre.

Det finnes fire måter å øke verdi på. Den vanligste er inntekter. En annen er å redusere kostnader. Hvis du produserer én million enheter i året og reduserer kostnaden med 50 cent per enhet, er det verdt en halv million dollar.

Den tredje måten er å redusere risiko. Da jeg var IT-direktør, hadde selskapet et datasenter som var koblet til hovedkontoret via en fiberkabel. En gang i året gravde noen opp kabelen med en gravemaskin og satte oss ut av drift en hel dag. Vi omsatte for omtrent én million dollar om dagen, så risikoen kostet én million dollar i året.

Jeg foreslo at vi flyttet datasenteret til et sikkert sted utenfor Sacramento, der selskaper som Google og Facebook hadde serverne sine. Vi brukte 50 000 dollar. Ville du brukt 50 000 dollar for å spare én million? Ja, selvfølgelig. Å redusere risiko er verdi.

Den fjerde måten å øke verdi på er å øke muligheter. Hvis du vinner ett av seks anbud, og kan gjøre noe som gjør at du vinner to av seks, kan du beregne pengene dette representerer og sammenligne dem med kostnaden ved tiltaket.

Galen Low: Produkteieren er altså ansvarlig for verdien og måler de ulike verdidriverne. Hvordan formidles dette tilbake til utviklingsteamet?

Fred Fowler: Produkteieren må måle og ta rasjonelle beslutninger om hva teamet skal arbeide med. Du kan ikke måle verdien av noe som ikke eksisterer. Derfor må produkteieren gjøre en kvalifisert gjetning om hva som vil være verdifullt, på samme måte som ved en investeringsbeslutning.

Teamet skaper verdien, og deretter legges resultatet i hendene på kundene for å finne ut hvor verdifullt det er. Man måler i etterkant, blant annet ved å finne ut hva folk vil betale for det, hvilke kostnader man sparer, og hvilken avkastning investeringen gir.

Hvis du bruker 50 000 dollar på en sprint, får du mer enn 50 000 dollar i verdi tilbake? Produkteieren og teamet sitter i samme båt. De må levere mer verdi enn det de koster.

Galen Low: Det er en veldig tydelig formulering. Vi tenker ofte at kunden selvfølgelig skal betale fordi vi har arbeidet 80 timer. Men da snakker vi om tid mot penger, ikke nødvendigvis om verdi.

Fred Fowler: Når utviklerne forstår dette, innser de at de har egeninteresse av å sørge for at arbeidet deres er verdifullt. Produkteieren har en forretningsrolle, mens utviklerne er teknikerne. Produkteieren sier hva som er ønskelig, utviklerne sier hva som er mulig, og gjennom en forhandling finner man ut hva som er praktisk.

Utviklerne bør ikke bare spørre hva de skal gjøre. De bør spørre om de kan løse problemet på en enklere måte. Hvis brukerne skal identifisere seg, trenger man kanskje ikke bygge et helt innloggingssystem. Man kan bruke innlogging med Google, Facebook, ansiktsgjenkjenning eller fingeravtrykk.

Utviklerne kan fortelle hva som er enkelt og vanskelig, mens produkteieren kan fortelle hva som er verdifullt. Forhandlingen handler om å finne den enkleste løsningen som skaper verdi.

Galen Low: Hvordan ser samtalen om verdi ut i teamene du har arbeidet med? Handler det om å optimalisere en bestemt måling, eller om å endre retning fra sprint til sprint?

Fred Fowler: Det henger sammen med kompensasjon. Hvis alle får betalt per time, er insentivet å gjøre alt på den vanskeligste måten. Jeg har arbeidet med et stort selskap som brukte to år og 500 millioner dollar på å bygge om alle forretningsprosessene sine. De hadde enorme mengder møter, rapporter og kode, men etter to år hadde de skapt ingen verdi. De hadde bare skapt støy, aktivitet og mange fakturerbare timer.

Kompensasjon har to sider. Først må du betale markedspris for å få folk inn døren. Deretter bør du kompensere for verdien de skaper. Hvis teamet skaper 100 000 dollar i verdi, kan selskapet for eksempel gi 20 prosent av dette til teamet. Teamet bør selv avgjøre hvordan belønningen fordeles, fordi de vet best hvem som bidro med hva.

Galen Low: Det minner om en overskuddsdelingsmodell: grunnlønn for å få folk inn, pluss et insentiv basert på skapt verdi.

Fred Fowler: Det gir riktige insentiver. Produkteieren er i praksis en investor og bør få myndighet til å investere teamets tid. Men resultatene av investeringene må måles. Utviklingsteamet bør ha full myndighet til å finne ut hvordan arbeidet skal gjøres.

Scrum sier at utviklingsteamene må være selvstyrte og tverrfunksjonelle. De må kunne skape produktet på egen hånd og ta sine egne beslutninger. Da kan de ikke skyve ansvaret over på andre når noe går galt.

Galen Low: Bransjen vår har ikke vært spesielt god til å fremme ansvarlighet. Ofte har budskapet vært: «Gjør det på denne måten fordi jeg sier det.»

Fred Fowler: Det er kontraproduktivt, fordi læringen fra arbeidet ikke påvirker dem som tar beslutningene. De som har myndighet, må også ha evnen til å gjennomføre. Det gjelder produkteieren, som må kunne investere store beløp, og utviklerne, som må kunne skape produktet som et team.

Scrum-masterens største utfordring er å få alle til å arbeide sammen som et team og forstå sitt eget ansvar. En kompensasjonsordning som belønner den faktiske verdien de skaper, kan hjelpe.

Galen Low: Mål verdi og belønn verdi.

Fred Fowler: Det er svært viktig at produktet en produkteier arbeider med, har en målbar verdi. Hvis du arbeider med noe der verdien ikke kan måles, er det ikke et produkt. Du har bare en del av et annet produkt, og det egentlige produktet bør styre beslutningene om utviklingen.

Galen Low: Kan dette fungere for andre metoder enn Scrum?

Fred Fowler: Ja. Scrum og smidig utvikling er lag oppå noe dypere. Det dypere prinsippet er at kvalifiserte mennesker må kunne ta beslutninger de er ansvarlige for, både når det gjelder forretning og produktutvikling. Utviklerne må kunne skape produktet og styre seg selv.

Uansett hvilket rammeverk du bruker, bør du måle verdi i stedet for aktivitet, og resultater i stedet for leveranser. Gjør dette, mål resultatene og lær av dem. Det er veien til suksess.

Galen Low: Der har dere det. Veldig bra.

Fred, hvor kan lytterne lære mer om møtegruppen og bøkene dine?

Fred Fowler: Jeg har drevet en møtegruppe siden 2015. Den handler om Scrum og heter Advanced Scrum Case Studies. Annenhver uke møtes vi på nettet, og jeg legger ut en case på forhånd. Vi diskuterer blant annet utfordringer med team i andre land og hvordan man måler verdi.

Møtegruppen heter Silicon Valley Professional Scrum meetup group. Du kan søke etter den på Meetup. Samlingene har gitt mye interessant materiale, og jeg har skrevet rundt 60 caser. Jeg har samlet dem i en bok som heter Advanced Scrum Case Studies. Den er tilgjengelig på Amazon og på nettstedet mitt: www.siliconvalleyscrum.com.

Galen Low: Det er veldig kult. Jeg visste ikke at boken var basert på materialet fra diskusjonene i møtegruppen.

Fred, tusen takk for at du ble med i programmet. Jeg likte historiene og perspektivet ditt veldig godt. Samtalen om kompensasjon kunne nesten vært en egen episode.

Fred Fowler: Takk. Jeg likte virkelig å snakke med deg. Takk for invitasjonen.

Galen Low: Hva synes du?

Er det realistisk for prosjektteam å orientere seg rundt verdiskaping i stedet for bygde timer eller fullførte brukerhistorier? Eller er vi for avhengige av en modell der arbeidstimer byttes mot penger?

Fortell oss en historie: Hvilke målinger har vært riktige å følge med på i prosjektene dine? Og hvilke endringer eller resultater har du sett etter å ha fått innsikt i prosjektdataene dine?

Del tankene dine i kommentarfeltet nedenfor!

Hvis du vil utvikle ferdighetene dine som strategisk prosjektleder, kan du bli med i fellesskapet vårt.

Gå til thedigitalprojectmanager.com/membership for å få tilgang til et støttende fellesskap som deler kunnskap, løser komplekse utfordringer og former fremtiden for faget vårt – sammen.

Fra solide maler og månedlige opplæringsøkter som sparer deg for tid og energi, til støtten fra kolleger gjennom Slack-diskusjoner, direktesendte arrangementer og mastermind-grupper: Som medlem av fellesskapet vårt har du over tusen mennesker i ryggen mens du navigerer karrieren din innen digital prosjektleveranse.

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.