På vei mot omforente metrikker i IT-bransjen

Det finnes ikke en konsensus i IT-bransjen rundt metrikker som hjelper oss å måle produktivitet og som setter utvikler-team i stand til å forbedre seg selv. Vi har gått gjennom forskning og funnet et tydelig budskap som forklarer hvorfor metrikker er så vanskelig: Metrikker bør brukes til å sette team i stand til å forbedre seg selv – ikke til å kontrollere og belønne dem. 
P.s. Dette blogginnlegget er skrevet av en eksternt samarbeidspartner og representant for SINTEF, og er en del av Knowit sin forskningssatsning på datadreven digital transformasjon. Les mer her. 

Metrikker i utforskningsfase

Metrikker er noe mennesker har holdt på med i tusen år og vi finner dem overalt. Vi målte størrelsen på fiskene vi fanget. Og tok tiden på idrettsutøvere tilbake til det gamle Hellas. I dag omgir vi oss med metrikker som KPIer, faktureringsgrader, medarbeiderundersøkelser osv.  

Siden starten av den industrielle revolusjonen har masseproduksjonen eksperimentert og kommet frem til omforente metrikker som er verdifulle. Man sjekket hvor lang tid det tok å gjennomføre oppgaver og eksperimenterte med nye produksjonsmåter for så å ta tiden på nytt. Man veide og målte ting som produseres, justerte på maskiner og målte på nytt for å verifisere at justeringen førte til forbedring. Flere av metrikkene kan man finne i Lean-litteraturen.  

IT-bransjen derimot er en ung bransje sammenlignet med produksjon. Vi er fortsatt i utforskningsfasen, og prøver å finne konsensus rundt metrikker for effektivitet og produktivitet.  

Eksempler på hvordan metrikker brukes i hverdagen for å
måle stemningen på hovedkontoret til Knowit i Oslo. 

Andre spilleregler i IT-bransjen

Hvorfor kan vi ikke bare adoptere metrikkene fra masseproduksjonen? Dessverre har vi andre spilleregler i IT-bransjen. For eksempel kan man ofte ikke ta på det som lages. Det kreves ikke store investeringer i materialer, fabrikker eller store logistikksystemer for å lage software som kan selges i stor skala. Man trenger i prinsippet kun noen kunnskapsrike mennesker og infrastruktur som i stor grad kan leies ved å knipse i fingrene. 

Forskning viser tydelige indikatorer 

Med andre ord må IT-bransjen finne sine metrikker selv. Vår gjennomgang av forskningen viser noen tydelige punkter: 

• Ikke gi andre innsikt i målingene enn teamet som faktisk skal bruke dem til å forbedre seg. Det kan føre til juks og uønskede arbeidsmønstre.  
   
  For å illustrere dette brukes ofte “flyplass-eksemplet”. En flyplass ønsket å måle hvor lang tid det tok å få bagasjen på bagasjebeltet etter et fly hadde landet.  To av bakkemannskap-teamene utmerket seg som mye raskere enn andre. Men det viste seg at de hadde ikke funnet noen ny metode eller forbedret seg. De hadde jukset. Det første de gjorde når flyet hadde parkert var å plukke ut én bag og sendte den på en bagasje-bil direkte inn til bagasjebeltet og fikk registrert “first bag on belt”. Metrikken viste at de var klart raskest og teamet høstet mye ros og belønning. Dette er et typisk eksempel på at når andre enn teamet får innsikt i en metrikk fører det til uønskede handlinger.   

• Metrikker gir aldri et fullstendig bilde på virkeligheten. For eksempel er det veldig vanlig å måle antall linjer kode. Om antall linjer kode går drastisk ned kan det skyldes at noen har slettet masse kode ved en feiltakelse eller det kan være en bevisst handling for å f.eks. gjøre codebasen mindre vedlikeholdskrevende. For å kompensere prøver mange å introdusere veldig mange metrikker for å prøve å fange det hele bildet. Dette fører ofte til at team slutter å følge med på metrikkene, det blir for mange av dem til at de evner å behandle alle.  
  
  

• Metrikker må være knyttet til et tydelig mål (goal). For eksempel er deployment frequency1 en metrikk som amerikanske forskere anbefaler for å få effektive team. Hensikten med målingen er at kode skal eksponeres for brukeren ofte så teamet kan få feedback på det de lager tidlig. En typisk feil mange gjør er at de blir så opptatt av metrikken at de glemmer hensikten (goal) med den. Man blir så opptatt av å få til en høy deployment frequency at man glemmer å investere tid i å utforske tilbakemeldingene fra brukerne.  

• Metrikker viser ansatte hva som er viktig for bedriften. Det som måles er det som får fokus. Måler man for eksempel antall linjer kode vil det få fokuset til utviklerne – selv om dette er ikke er noe brukerne ikke bryr seg om. Dette er en typisk fallgruve, man innfører målinger som bidrar til handlingsmønstre som ikke er viktig for bedriftens kjernevirksomhet. 
  
  

Forskningsprosjektet Transformit

I forskningsprosjektet Transformit skal vi teste metrikkene som Google foreslår for å sjekke om de er valide i Norge. I tillegg skal vi teste noen forslag fra andre amerikanske forskere (fotnote 2) til hvordan måling kan hjelpe developer-teams å forbedre seg. Lurer du på noe, ta gjerne kontakt.

Vil du vite mer om Knowit sin satsning på forskning?
Trykk på knappen under. 

Referanser

Fotnote 1 og 2) Forsgren, N. et al. The SPACE of Developer Productivity. Queue 19, 20–48 (2021). 

Andre referanser til forskning:  

• Bouwers, E., Visser, J. & Deursen, A. van. Getting what you measure. Commun Acm 55, 54–59 (2012). 

• Forsgren, N. & Kersten, M. DevOps Metrics. Queue 15, 19–34 (2017). 

• Kupiainen, E., Mäntylä, M. V. & Itkonen, J. Using metrics in Agile and Lean Software Development – A systematic literature review of industrial studies. Inform Software Tech 62, 143–163 (2015)