Måling af travlhed kontra måling af resultater

 

Læs transskriptionen:

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Galen Low: Popquiz: Du er halvvejs gennem dit projekt, og alle dine målinger ser gode ud. Din leverandør har brugt det aftalte antal timer, og dit teams hastighed og udnyttelse er præcis, som du havde planlagt.

Men på trods af, at dit projekt ser sundt ud, bliver produktet ved med at ramme ved siden af i fokusgrupper og brugertests. Den teknologi, som din ledende sponsor insisterede på, er hurtigt ved at blive forældet, hvilket gør det vanskeligt at foretage ændringer. Og dit teams moral er lav: Når du beder dem om løsninger, trækker de på skuldrene og siger, at de gjorde det, de blev bedt om, inden for den tildelte tid.

Så hvordan kan dit projekt være sundt, selv om resultatet ikke skaber den tilsigtede værdi?

Hvis du oplever, at dine projektmålinger måler travlhed mere end værdi, så lyt videre. Vi dykker ned i den praktiske mekanik bag, hvordan projektteams kan måle værdi, og udforsker idéer til at flytte incitamentet fra brugte timer til skabt værdi.

Hej allesammen, og tak fordi I lytter med. Mit navn er Galen Low fra Digital Project Manager. Vi er et fællesskab af digitale fagfolk med en mission om at hjælpe hinanden med at blive dygtigere, mere selvsikre og bedre forbundet, så vi kan øge værdien af projektledelse i en digital verden. Hvis du vil høre mere om det, så gå til thedigitalprojectmanager.com.

Okay. I dag taler vi om forskellen mellem at måle projektets sundhed og fremdrift kontra at måle projektets succes. Er det nok at følge teamets hastighed og omkostningsresultater? Eller er det også vores ansvar som projektledere at måle projektets resultater og effekt?

Med mig i dag har jeg Fred Fowler – en certificeret Scrum Master på niveau 3, som har udgivet flere bøger om Scrum-metoden, er arrangør af Silicon Valley Professional Scrum-mødegruppen med omkring 2.000 medlemmer, leder et lignende Scrum-fællesskab i Shanghai i Kina og organiserede den første Silicon Valley Scrummit-konference. Med andre ord: en person, der ved en ting eller to om Scrum.

Velkommen, Fred!

Fred Fowler: Hej! Tak, fordi jeg måtte være med i programmet.

Galen Low: Det er fantastisk at have dig med.

Fred Fowler: Jeg præsenterer mig selv som en Scrum-fyr. Selvom nogle måske vil sige, at jeg er Scrum-lækker.

Galen Low: Det er bedre end, at jeg kalder Fred for Scrum-jordens salt.

Fred Fowler: Der er alle mulige måder, man kan lege med ordet Scrum på. Man kan være en Scrum-bag og alt muligt andet. Nå, men fortsæt endelig.

Galen Low: Nemlig. Fantastisk. Du har en meget interessant baggrund, og jeg tror, den vil give vores lyttere masser af kontekst for dit syn på projektmålinger. Hvis jeg har forstået det rigtigt, begyndte du som computerprogrammør, gik derefter ind i politik, blev borgmester og endte siden som CIO, før du begyndte at bruge din sjældne Scrum Master-certificering på niveau 3 til at hjælpe andre.

Jeg vil gerne høre, om du kan fortælle os lidt om din rejse, og hvordan dine erfaringer har formet den måde, du ser tingene på i dag?

Fred Fowler: Jeg vil sige, at min karriere mindede om at være inde i en flippermaskine.

Jeg begyndte som programmør tilbage i 1980. Dengang arbejdede man på en maskine, der var så stor og tung, at der næsten krævedes særligt udstyr for at flytte den, og som var mindre kraftfuld end en almindelig telefon eller smartphone i dag. Men vi drev en afdeling i en halvledervirksomhed ved hjælp af den, og det var dér, jeg lærte mine færdigheder.

Jeg gik videre, fordi det var Silicon Valley i de tidlige dage, hvilket betød en masse omskiftelighed. I de første otte år af min karriere arbejdede jeg for fem forskellige virksomheder, og det var, som jeg siger, utrolig omskifteligt. Til sidst tænkte jeg, at jeg havde brug for jobsikkerhed, så jeg måtte hellere arbejde for mig selv.

Jeg blev konsulent og arbejdede for 60 forskellige virksomheder i løbet af de næste ti år. Igen lavede jeg grundlæggende det samme: Jeg forsøgte altid at anvende teknologi til at løse forretningsproblemer, hvilket i virkeligheden er det, det hele handler om. Så var der en virksomhed, jeg arbejdede for som konsulent.

De gav mig et tilbud, jeg ikke kunne afslå. Jeg endte med at lede deres IT-drift og blev, som jeg siger, CIO. Jeg implementerede en masse teknikker, som i sidste ende viste sig at være Scrum-teknikker, selvom jeg ikke var klar over det på det tidspunkt. Jeg gav folk mulighed for at løse problemer og begrundede arbejdet ud fra investeringsafkastet.

Dengang lavede jeg mange projekter, som virkelig formede mit samlede syn på, hvordan man organiserer foretagender. Mange ting er jeg stolt af. Virksomheden havde arbejdet hårdt på at opbygge en hjemmeside ved hjælp af en stor, velkendt computerproducent med et navn på tre bogstaver.

De betalte en kvart million dollars til virksomheden for at få lavet en temmelig elendig e-handelsløsning. Jeg blev involveret og så, at der var en stor mulighed for forbedring. Så jeg organiserede et projekt og organiserede lange Scrum-forløb.

Vi havde to forskellige teknologier involveret. Der var et ældre system, en IBM-minicomputer, der dengang blev kaldt AS/400. Det var backend-delen, men vi havde brug for en frontend. Derfor rejste jeg til Kina og fandt en lille virksomhed, som var ambitiøs og kunne lave frontend-delen. Vi organiserede det sådan, at det amerikanske team lavede backend-arbejdet, mens det kinesiske team lavede frontend-arbejdet. Det eneste, vi skulle finde ud af, var, hvordan de to platforme skulle kommunikere med hinanden.

Det viste sig at være ret enkelt. Vi erstattede et stykke arbejde til en kvart million dollars med en hjemmeside, som inden for seks måneder stod for 40 % af virksomhedens forretning, og det kostede 14.000 dollars at lave. 14.000 dollars. Det var enkelt: Folk, der forstod teknologien, skulle have frihed til at arbejde, et problem at løse og mulighed for selv at løse det.

Man kan godt have teams forskellige steder i verden. Det er ikke et problem. Det eneste, man skal gøre, er at styre, hvordan de arbejder sammen.

Galen Low: Præcis. Lean-teams, datakontrakt, og så er man af sted.

Fred Fowler: Netop. Og det, der virkelig var afgørende, var at forstå, hvad der var vigtigt at måle.

Når man taler om offshore-teams og den slags, går alle i panik og spørger: Hvordan ved vi, hvad de laver? Så vil man have alle mulige værktøjer til at måle, hvor hårdt de arbejder, og hvor travle de er, fordi man ønsker, at de skal være travle hele tiden.

Men gæt hvad? Det er ligegyldigt. Det gør ingen forskel, om de medarbejdere, der arbejder offshore, er travle eller ej. Det er ikke vigtigt. Det vigtige er, hvad de rent faktisk leverer, og hvilken værdi deres leverancer skaber. Det er det, man bør måle. Glem alt om at holde stopure over folk. Det er ligegyldigt, hvor mange timer de bruger.

Her er et eksempel: Hvis du havde et team på over 200 personer, der arbejdede otte til ti timer om dagen i to år, sammenlignet med et team på måske fem, seks eller ti personer, der arbejdede normale arbejdstider i ét år, hvem tror du så ville levere mest værdi? Det viste sig, at de 200 personer, der arbejdede i to år, skabte det, der kaldes healthcare.gov, en hjemmeside fra mange år tilbage, som endte som en total katastrofe.

Den skulle implementere Obamacare. Den brød sammen, fordi de 200 mennesker blev målt på, hvor travle de var. De ti personer i det følgende år var dem, der omskrev det hele og fik det til at fungere. De leverede langt mere værdi end de 200 andre.

Galen Low: Lad os dykke ned i det, for jeg synes, det er en vigtig pointe. Du nævnte en af grundene til, at vi måler travlhed, men i min verden, hvor jeg kommer fra bureauer og konsulentvirksomheder, handler det hele om fakturerbare timer. Det handler om udnyttelsesgrad. Det handler om, hvor mange fejl vi har rettet, eller hvor mange opgaver vi har afsluttet.

Hvorfor har vi denne tendens til at måle travlhed?

Fred Fowler: Det er enkelt. Det er, fordi det er nemt at måle. Alt, hvad du behøver for at måle, hvor travle folk er, er et ur. Alt, hvad du behøver for at finde ud af, om folk overholder en række deadlines, er en kalender. Det er let at måle. Og ved du hvad? Det danner grundlag for aflønningen.

Du nævnte fakturerbare timer. Det er en stor fejlslutning. Ideen om, at menneskers tid er værdifuld. Menneskers tid er værdifuld for dem selv, men det, der er værdifuldt for dig, er, hvad de gør med den tid. Det ville være langt bedre, hvis verden havde en god målestok til at måle resultaterne af den tid, folk bruger.

Når jeg taler med virksomheder, forsøger jeg at fortælle dem, at det vigtigste, de skal gøre, er at finde ud af, hvilken værdi de ønsker skabt, og dele den op i meningsfulde dele, så den kan måles. Derefter skal de måle fremdriften ud fra den skabte værdi. Inden for lean findes idéen om et minimum levedygtigt produkt.

Man laver så meget af et produkt, som er nødvendigt for at få noget i kundens hænder. Hvorfor er det en god idé? Fordi det, man giver kunden, har værdi, netop fordi det er i kundens hænder. Kunden kan fortælle dig, hvor værdifuldt det er. På den måde kan du vurdere, om den skabte værdi stod mål med den udgift, du havde for at skabe den.

Hvis du har en app, der koster en halv million dollars at udvikle, er det så en god investering? Det afhænger af, om appen kommer på iTunes og bliver downloadet tre millioner gange til to dollars stykket. Så har du tjent seks millioner dollars på en investering på en halv million dollars.

Det er en god handel. Det ville jeg gøre hver dag. Hvis du bruger den samme halve million på at lægge appen på iTunes, men den kun bliver downloadet 20.000 gange til to dollars, så lad os sige 25.000 downloads. Det betyder, at du har brugt 500.000 dollars på at skabe en værdi på 50.000 dollars. Den samme indsats og det samme antal fakturerbare timer, men resultatets værdi er anderledes. Og det er resultatets værdi, der er vigtig.

Galen Low: Du berørte noget virkelig vigtigt dér, som jeg ikke ved, om alle fuldt ud forstår ved det minimum levedygtige produkt. Vi måler travlhed, fordi det nogle gange handler om tillid. Vi stoler ikke på, at folk faktisk gør noget, men hvis vi kan holde et ur op foran dem, mens de arbejder, ved vi i det mindste, at de har arbejdet i de timer.

Men som du siger, måler det ikke værdi. Folk kommer til mig og siger: Selvfølgelig har vi brug for fakturerbare timer. Det er kontrakten. Det er sådan, folk bliver betalt. Det er aftalen. Men det, jeg godt kan lide ved det, du siger om det minimum levedygtige produkt, er: Lad os få noget ud i verden.

Det kræver en investering. Derefter kan kunden afgøre, om det er værdifuldt eller ej. Nogle vil måske sige, at de gerne vil vide, om det er værdifuldt, før de bruger pengene. Men i virkeligheden fungerer det heller ikke sådan. Man siger: Jeg har 50.000 dollars. Vi bygger produktet. Og efter at have brugt de 50.000 dollars har man måske stadig ikke skabt det, man ønskede, eller noget, der skaber værdi.

Føler du, at fakturerbare timer og dollars er et nødvendigt onde for at få forretningen til at fungere, eller bør vi forsøge at bevæge os ud over det?

Fred Fowler: På nogle måder er det et nødvendigt onde. Men man skal stadig holde folk på rette spor ved at sammenligne deres omkostning med værdien af resultatet. Her er noget vigtigt ved Scrum-rammeværket: Inden for Scrum skal man altid skabe noget, der er færdigt, afsluttet og klar til at blive givet til kunden ved slutningen af hvert sprint.

Hvorfor tror du, det er sådan? Hvorfor er det vigtigt, at noget skal være færdigt, klar til kunden og kunne gives videre? Hvorfor tror du det?

Galen Low: Jeg vil vove at sige, at det er, så værdien kan måles.

Fred Fowler: Netop. Noget har kun værdi, når det er færdigt og klar til at blive givet til kunden.

Og sådan måler man værdi. Man måler værdi ud fra, hvor meget en kunde vil betale for det. I Scrum skaber man hver anden uge noget af værdi, så man kan måle denne værdi og sammenligne den med omkostningen ved at skabe den. På den måde ved man, om man er på rette vej til at skabe et produkt til seks millioner dollars med en investering på 50.000 eller 500.000 dollars, eller et produkt til 50.000 dollars med en investering på 500.000 dollars. Man skal kunne dele arbejdet op i dele, som hver har en målbar værdi, ikke bare noget, man synes har værdi. Målbar værdi.

Det er noget af det, Scrum lægger vægt på. Man træffer beslutninger på baggrund af ting, man måler, ikke gæt eller holdninger. Og det vigtigste at måle er værdi.

Galen Low: Kan du gennemgå, hvordan man måler værdi? Hvis det ikke er særlig nyttigt at måle travlhed, hvilke målinger bør vi så følge som team eller som Scrum-team i dette scenarie? Det lyder, som om du siger, at man ikke bare skal placere noget på en hylde, men faktisk få det ud på markedet.

Hvem vurderer, om noget er værdifuldt fra sprint til sprint, og hvordan følger man det?

Fred Fowler: Først og fremmest er det en god idé at forstå, at målingen af værdi i Scrum-rammeværket reelt kun er én persons opgave. Scrum deler ansvaret i tre dele: Produktejeren, udviklerne og Scrum Masteren.

Produktejerens opgave er at maksimere værdien af teamets arbejde. Produktejeren er ansvarlig for værdien. Man kan ikke maksimere noget, medmindre man kan måle det. Hvis man ikke kan måle det, man forsøger at maksimere, har man ingen idé om, hvorvidt ens handlinger gør det bedre eller værre.

Der er fire måder, man kan øge værdien på. Den mest almindelige er omsætning. Man kan lave en app og sælge tre millioner eksemplarer til to dollars stykket. Så kan man måle appens værdi til seks millioner dollars. En anden måde er at reducere omkostningen.

Hvis man producerer en million enheder om året og reducerer omkostningen med 50 cent, er det en værdi på en halv million dollars. Den tredje måde er at reducere risiko. Den fjerde måde er at øge mulighederne. Hvis man vinder ét udbud ud af seks, og man kan gøre noget, der øger sandsynligheden for at vinde to ud af seks, kan man beregne de involverede penge og sammenligne dem med omkostningen ved indsatsen.

Galen Low: Produktejeren er altså ansvarlig for værdien og måler den gennem disse fire måder at øge værdi på. Hvordan fører de så denne information tilbage til udviklingsteamet?

Fred Fowler: Produktejerens opgave er at måle værdien og træffe rationelle beslutninger om, hvad teamet skal arbejde på. Man kan ikke måle værdien af noget, der ikke eksisterer. Derfor må produktejeren i praksis gætte på, hvad der bliver værdifuldt. Det er en investeringsbeslutning, ligesom når man køber aktier.

Man foretager et kvalificeret gæt, leder teamet mod at skabe værdien og giver derefter resultatet til kunderne for at finde ud af, hvor værdifuldt det er. Man måler det bagefter, men bruger målingen til fremtidige investeringsbeslutninger.

Hvis man bruger 50.000 dollars på et sprint, får man så mere end 50.000 dollars i værdi ud af det? Produktejeren og teamet er i samme båd. De skal levere mere værdi, end de koster.

Galen Low: Det er en meget klar formulering. Ofte tænker vi: Selvfølgelig skal de betale mig. Jeg arbejdede 80 timer, som jeg sagde, jeg ville. Hvorfor skulle de ikke betale mig? Men så handler samtalen om tid for dollars og ikke nødvendigvis om værdi.

Fred Fowler: Når udviklerne forstår det, indser de, at de har en interesse i at sikre, at det, de laver, er værdifuldt. Produktejeren har en forretningsrolle, mens udviklerne har den tekniske rolle. Produktejeren identificerer, hvad der er ønskværdigt, og udviklerne fortæller, hvad der er muligt.

Gennem en forhandling finder man ud af, hvad der er praktisk. Man finder den letteste løsning, der skaber værdi, og bygger den på en måde, så den kan gives til en kunde og måles.

Galen Low: Jeg har selv været skyldig i at måle travlhed eller hastighed. Vi måler stadig hastighed og bruger vores nedbrændingsdiagrammer. Hvordan foregår samtalen om værdi i de Scrum-teams, du har arbejdet med?

Fred Fowler: Det hænger sammen med aflønning. Hvis alle bliver betalt pr. time, er incitamentet at gøre tingene på den besværlige måde. Mange projekter er ramt af den sygdom. Jeg arbejdede med en Fortune 50-virksomhed, som brugte to år og 500 millioner dollars på at omlægge alle deres forretningsprocesser.

De havde en hær af mennesker, som havde travlt. Der var møder, rapporter og kode. Jeg lærte dér udtrykket “kode til bortkastning”. De skrev noget, som de troede, de havde brug for, men bagefter viste det sig, at de ikke havde brug for det.

Efter to år og det meste af de 500 millioner dollars havde de ikke skabt nogen værdi. De havde skabt en masse støj og aktivitet, brugt mange fakturerbare timer og udført en masse arbejde, der viste sig at være nytteløst.

Der er to aspekter ved aflønning. For det første skal man have folk ind ad døren, og derfor skal man betale markedsprisen. For det andet skal man belønne den værdi, folk skaber. Hvis et team skaber værdi for 100.000 dollars, kan virksomheden måske give 20 % til teamet. De bør få beløbet som team og selv beslutte, hvordan det fordeles, fordi de ved bedst, hvem der fortjener belønningen.

Galen Low: Det minder om en model med overskudsdeling, hvor man ser på resultaterne for kvartalet og fordeler bonusser. Det, du siger, er en grundløn for at få folk ind ad døren plus et incitament baseret på den værdi, der skabes og måles konsekvent af produktejerne.

Fred Fowler: Det giver mening, fordi det placerer alle incitamenter rigtigt. Produktejeren er grundlæggende en investor. Giv produktejeren myndighed til at investere teamets tid, men mål resultaterne af investeringerne.

Udviklingsteamet skal have fuld myndighed til at finde ud af, hvordan arbejdet skal udføres. Ingen bør fortælle dem, hvad de skal gøre. Når udviklerne selv har myndigheden til at træffe beslutningerne, har de ingen andre at give skylden end sig selv.

Galen Low: Vores branche har ikke været god til at skabe ansvarlighed. Mange af vores adfærdsmønstre har været: Gør det på denne måde, fordi jeg siger det.

Fred Fowler: Det er kontraproduktivt, fordi de erfaringer, der opstår under arbejdet, ikke påvirker dem, der træffer beslutningerne. Derfor siger Scrum, at udviklingsteams skal være selvstyrende og tværfunktionelle. De skal kunne skabe produktet selv og organisere og lede sig selv.

Der er tre ting, der skal være til stede: myndiggørelse, ansvarlighed og kompetence. De mennesker, der får myndighed, skal være i stand til at udføre arbejdet. Produktejeren skal kunne investere store beløb i at skabe værdifulde produkter. Udviklerne skal kunne skabe produktet som et team og dermed være ansvarlige for resultatet.

Scrum Masterens største udfordring er at få alle til at arbejde sammen som et team og forstå deres eget ansvar. En aflønning, der belønner den faktiske værdi, kan hjælpe. Når folk forstår, at de kun får en bonus, hvis de skaber målbar værdi, begynder de at arbejde anderledes.

Galen Low: Mål værdi, og beløn værdi.

Fred Fowler: Ja. Det er meget vigtigt, at et produkt har en målbar værdi. Hvis man arbejder på noget, men ikke kan måle dets værdi, er det ikke et produkt, og man kan ikke træffe rationelle beslutninger om det.

Et produkt er noget, der kan produceres, og som har en objektivt målbar værdi. Man måler produktet ved at sælge det eller få nogen til at betale for det. Hvis man ikke kan sælge noget eller få nogen til at betale for det, har man ikke et produkt, men en del af et andet produkt.

Galen Low: Vi har talt meget om Scrum, og jeg ved, at du er stor tilhænger af Scrum. Men når det gælder måling af værdi og effekt i stedet for travlhed, kan det så fungere med andre metoder?

Fred Fowler: Andre metoder? Ja. Scrum er et lag oven på noget dybere. Agile er også et lag oven på noget dybere.

Scrum handler om at skabe produkter uden at følge en fast opskrift. Vandfaldsmodellen handler om planlægning og om at skabe en opskrift, som en gruppe mennesker skal følge trin for trin. Problemet er, at ting ændrer sig.

Derfor bør man arbejde i inkrementer, observere, hvad man gør, lære og fokusere på at måle værdi i stedet for aktivitet og resultater i stedet for output. Det er vejen til succes.

Galen Low: Sådan er det, folkens. Meget interessant.

Fred, hvor kan lytterne lære mere om din mødegruppe og dine bøger?

Fred Fowler: Jeg har drevet en mødegruppe siden 2015, som handler om Scrum. Den hedder Advanced Scrum Case Studies.

Hver anden uge mødes vi online, og jeg lægger en case op på forhånd. Det kan handle om offshore-teams, måling af værdi eller andre udfordringer. Gruppen hedder Silicon Valley Professional Scrum meetup group og kan findes på Meetup.

Mødegruppen har skabt en masse interessant materiale. Jeg har noter til omkring 60 cases og har samlet dem i en bog med titlen Advanced Scrum Case Studies. Den findes på Amazon og på min hjemmeside: www.siliconvalleyscrum.com.

Galen Low: Det er virkelig interessant. Jeg vidste ikke, at bogen var baseret på materialet fra diskussionerne i mødegruppen.

Fred, mange tak, fordi du deltog i programmet i dag. Jeg nød virkelig dine historier og dit perspektiv. Samtalen om aflønning kunne sagtens være et helt afsnit i sig selv.

Fred Fowler: Tak. Jeg nød virkelig at tale med dig. Tak, fordi jeg måtte være med.

Galen Low: Hvad synes du?

Er det realistisk for projektteams at fokusere på værdiskabelse i stedet for fakturerede timer eller afsluttede brugerhistorier? Eller er vi for afhængige af en model, hvor penge udveksles for arbejdstimer?

Fortæl os en historie: Hvilke målinger har været de rigtige at følge i dine projekter? Og hvilke ændringer eller resultater har du set, fordi du har haft indsigt i dine projektdata?

Skriv dine tanker i kommentarerne nedenfor!

Hvis du vil skærpe dine færdigheder som strategisk projektleder, så kom med i vores fællesskab!

Gå til thedigitalprojectmanager.com/membership for at få adgang til et støttende fællesskab, der deler viden, løser komplekse udfordringer og sammen former fremtiden for vores fag.

Fra robuste skabeloner og månedlige træningssessioner, der sparer dig tid og energi, til den kollegiale støtte gennem vores Slack-diskussioner, livearrangementer og mastermind-grupper betyder et medlemskab, at du har over tusind mennesker i ryggen, mens du navigerer i din karriere inden for digital projektlevering.

Hvis du kunne lide det, du hørte i dag, så abonnér og hold kontakten på thedigitalprojectmanager.com.

Vi lyttes ved næste gang. Tak, fordi du lyttede.