Måle utviklerteams produktivitet? – Det kan være best å la være, mener forsker

Forskeren som skal forske på måling av utviklerteamene produktivitet, vil egentlig anbefale IT-ledere å la være å måle.

– Det er så mange fallgruver. Det er ikke sikkert at man får den endringen ut av målingen man håpet at man skulle få, sier Tor Sporsem, forsker i Sintef, til Digi.no.

Vi møter ham sammen med Torbjørn Moen, direktør for forretningsutvikling offentlig sektor, i Knowit Objectnet AS, i et videomøte.

Sammen med Nav, Digitaliseringsdirektoratet, Entur, Oslo Origo og Kartverket skal de forske på hvordan det å måle produktivitet og effektivitet kan påvirke utviklerteam.

Prosjektet har fått 16 millioner kroner i støtte fra Forskningsrådet, og skal utforske datadrevet digital transformasjon. Det favner bredt. Alt fra hybride arbeidsformer og dataeierskap, til hvordan utviklerteam kan bruke data om seg selv til å forbedre seg er gjenstand for forskernes undersøkelser.

Målet er å gi forskningsbasert kunnskap tilbake til bransjen fortløpende.

– Forskning ligner på mange måter på programvareutvikling. Vi kan iterere og samarbeide og levere til bedriftene vi jobber med fortløpende, for så å få tilbakemeldinger om det vi har funnet ut er nyttig, sier Sporsem.

Utgangspunktet for forskningsprosjektet er at måling av produktivitet er vanskelig.

Risikosport

– Måling er så komplekst. Hvis man ikke skjønner at dette er en kjempeutfordring så bør man ikke måle i det hele tatt, sier Sporsem.

Virkeligheten er sammensatt, og kvantitative målinger kan gi et skjevt bilde. Samtidig risikerer du å flytte oppmerksomhet fra viktige til uviktige ting.

– Det du velger å måle vil vise hva bedriften synes er viktig. Dersom du velger noe som egentlig ikke er kjernevirksomhet, risikerer du å snu fokuset til veldig mange ansatte. Det er risikosport, sier Sporsem.

Dersom du tror du kan påvirke handlinger gjennom å sette i gang med målinger, må du være spesielt forsiktig, mener Sporsem, og trekker frem et eksempel fra måling av effektivitet i bagasjehåndtering på en flyplass.

Da ledelsen på flyplassen begynte å måle hvor lang tid det tok å få bagasjen fra flyet til bagasjebåndet, begynte et av teamene å plukke én bag fra flyet, for å haste den alene på en bli til bagasjebeltet. De fikk mye ros og belønning, men resultatet ble på ingen måte bedre for passasjerene.

– All forskning viser at så fort du begynner å vise frem målingene til noen andre enn teamet selv, så skjønner de som blir målt at tallene vil påvirke dem. Da begynner man å finne måter å jukse på, det er helt menneskelig, sier Sporsem.

Derfor er det bare teamet selv som bør ha innsyn i målingene, mener han.

Bare teamet bør få se målingene

Det er også i god smidig-ånd å holde målingene konfidensielle mener Moen.

– Det skal være opp til teamet å finne ut hvordan de skal bruke målingene. Hensikten er at de skal få et verktøy som de kan bruke til å forbedre seg selv, sier Moen og fortsetter:

– Derfor er det viktig at teamene ikke får innsyn i hverandres tall, og at vi har god sikkerhet og tilgangskontroll i plattformen vi bygger.

De vil også sikre at det ikke er mulig å skille ut enkeltindivider. Er det færre enn fem personer i teamet er det nok ikke så lurt å måle, mener Sporsem.

– Det er viktig at man ikke får individuelle scoringer, fordi folk fort kan føle seg truet, begynne å jukse og finne måter å manipulere tallene på, sier han.

Det er også viktig at det ikke blir ekstraarbeid med målingene, som ekstra registrering i Jira eller Azure Devops, mener Moen.

– Vi kobler dataplattformen rett til Github, det skal ikke koste teamet noe, sier han og legger til: – Også har vi som utgangspunkt at det er farlig å måle.

For å lykkes må teamet klare å sette seg ned og reflektere i fellesskap, og opprettholde en åpen og utforskende tilnærming.

– Forskningen viser at de som lykkes er de som greier å utforske rotårsaker, sier Sporsem.

Hva skal man måle?

IT-bransjen er ung, og det finnes fortsatt ingen standarder for hva man skal måle for å si noe om kvalitet og effektivitet i programvareutvikling.

Antall kodelinjer blir mye brukt som mål, men er vanskelig å lese noe fornuftig ut av mener de to. Rydding av teknisk gjeld kan gi færre kodelinjer, sanering av funksjonalitet kan gjøre at kodelinjer forsvinner.

– I tillegg så bryr jo ikke brukeren seg om hvor mange kodelinjer det er, sier Sporsem.

I forskningsprosjektet tar de utgangspunkt i fire mål som er identifisert som nyttige av amerikanske forskere. Google foreslår nettopp disse målene i sitt Devops-rammeverk.

• Hyppighet i produksjonssetting – Hvor ofte lykkes man med å levere ny funksjonalitet?
• Ledetid for endringer – Hvor lang tid det tar fra en utvikler sender inn koden (commiter) til den er i produksjonsmiljøet?
• Følgefeil-rate – Hvor stor andel av endringene fører til feil i produksjonsmiljøet?
• Gjenopprettingstid – Hvor lang tid det tar en organisasjon å komme seg etter en feil i produksjonsmiljøet?

Alle disse målene har fallgruver, mener Sporsem. Men samlet kan det hende de vil gi utviklerteamene et nyttig verktøy til å forbedre seg selv.

Setter man for eksempel hyppighet i leveranser som et mål, risikerer man å bli så opptatt av å produksjonssette ofte, at man glemmer hensikten med hyppige leveranser – å investere tid i å utforske tilbakemeldingene fra brukerne.

– Så kan man si: «Se nå har vi nådd en høy måling», samtidig som man går glipp av hensikten, sier Sporsem.

Dersom man vil måle hvor lang tid det tar fra en utvikler sender inn kode til den faktisk blir satt i produksjon, risikerer man å få interne konkurranser, der utviklere peker på hverandre, istedenfor å utforske hva som kan gjøres annerledes.

På samme måte kan overdreven oppmerksomhet på kvalitetsmål virke mot sin hensikt.

– Man kan bli så opptatt av kvalitet at man glemmer at det er lov å gjøre feil, sier Moen.

Derfor er det viktig å se disse målene sammen. Men om de vil fungere i norsk sammenheng, er for tidlig å si, mener de to.

Om et år kan det hende vi sitter med noen svar, men det kan også hende vi sier at nei, dette var ikke nyttig forskning for partnerne i prosjektet, så dette la vi fra oss, sier Sporsem.