KPI’er, der hjælper ledelsen med at træffe bedre beslutninger.
Azure DevOps, Jira, GitHub, ServiceNow og en lang række andre platforme producerer enorme mængder information hver eneste dag. Alligevel oplever mange ledergrupper, at de har svært ved at svare på nogle af de mest grundlæggende spørgsmål: Leverer vi hurtigere end sidste kvartal? Er kvaliteten blevet bedre? Kan vi stole på vores roadmap? Og bliver de investeringer, vi foretager i udviklingsorganisationen, omsat til reel forretningsværdi?
Det paradoks møder vi ofte. Organisationen har flere dashboards end nogensinde før, men ledergruppen føler sig ikke nødvendigvis bedre informeret. Årsagen er sjældent, at data mangler. Den er oftere, at der måles på det, der er let at hente ud af værktøjerne, frem for det, der hjælper ledelsen med at forstå organisationens evne til at levere.
Når vi hjælper virksomheder med at etablere KPI’er, starter vi derfor sjældent med at spørge, hvilke rapporter de allerede har. Vi starter med at spørge, hvilke beslutninger ledelsen gerne vil kunne træffe. Først derefter giver det mening at diskutere, hvilke målinger der kan understøtte de beslutninger.
Et af de mest udbredte eksempler er velocity. Mange organisationer rapporterer fortsat velocity til ledelsen, selvom metrikken oprindeligt blev udviklet som et planlægningsværktøj for det enkelte Scrum-team. Formålet var aldrig at sammenligne teams eller dokumentere organisatorisk performance. Velocity fortæller ganske enkelt, hvor meget arbejde et team historisk har gennemført inden for sin egen definition af Story Points. Det gør den nyttig for teamet selv, men meget lidt egnet som styringsværktøj på ledelsesniveau.
Forestil dig to udviklingsteams, der begge leverer omkring 50 Story Points pr. sprint. På papiret ser de ens ud. Men virkeligheden kan være vidt forskellig. Det første team deployer til produktion flere gange om ugen, har få fejl og modtager hurtig feedback fra brugerne. Det andet team afleverer ganske vist lige så mange Story Points, men funktionerne ligger efterfølgende flere uger i test, afventer godkendelser eller venter på, at et andet team bliver færdigt. Begge teams har samme velocity, men organisationens evne til at skabe værdi er markant forskellig.
Det samme gælder antallet af afsluttede User Stories eller Work Items. Mange dashboards viser udviklingen måned for måned, fordi tallene er nemme at hente fra Azure DevOps eller Jira. Men antallet af afsluttede opgaver siger i sig selv meget lidt om organisationens performance. Hvis en organisation reducerer antallet af leverede User Stories med 20 procent, men samtidig halverer Lead Time, øger kvaliteten og leverer større forretningsmæssige initiativer, er det svært at argumentere for, at organisationen er blevet mindre effektiv. Tværtimod kan det være et tegn på, at den er blevet bedre til at fokusere på det arbejde, der skaber størst værdi.
Det er blandt andet derfor, DORA-målingerne fortsat har en så central plads i moderne softwareudvikling. Deployment Frequency, Lead Time for Changes, Change Failure Rate og Mean Time to Recovery fokuserer ikke på aktivitet, men på organisationens evne til hurtigt og stabilt at omsætte idéer til software i produktion. De beskriver forskellige sider af den samme proces og giver tilsammen et langt mere retvisende billede af leveranceevnen end traditionelle aktivitetsmål.
Selv DORA-målingerne giver dog kun en del af historien. De fortæller, hvordan organisationen leverer, men ikke nødvendigvis hvorfor. Det kræver, at man også ser på flowet gennem organisationen. Hvor mange opgaver er i gang samtidig? Hvor længe ligger de stille? Hvor mange bliver blokeret af afhængigheder? Hvor stor en del af gennemløbstiden bruges reelt på værdiskabende arbejde?
Her bliver metrikker som Work In Progress, Flow Efficiency, Work Item Age og Blocked Work Ratio interessante. Ikke fordi de skal rapporteres til bestyrelsen hver måned, men fordi de hjælper ledergruppen med at forstå de mekanismer, der påvirker leveranceevnen. En stigende Lead Time skyldes sjældent, at udviklerne programmerer langsommere. Den skyldes oftere, at organisationen har for mange initiativer i gang samtidig, at beslutninger træffes for sent, eller at teams bliver afhængige af hinanden på uhensigtsmæssige måder. Den slags bliver først synligt, når man begynder at måle flow frem for aktivitet.
Det interessante er, at mange af de største forbedringer ikke kræver nye værktøjer eller flere udviklere. De opstår, når ledelsen begynder at prioritere anderledes. Vi har flere gange oplevet organisationer, der ønskede at forbedre deres leveranceevne ved at ansætte flere udviklere. Da vi analyserede deres data, viste det sig, at den største udfordring ikke var kapacitet, men ventetid. Opgaver lå stille mellem analyse, udvikling, test og godkendelse, og Work In Progress var langt højere, end organisationen kunne håndtere. Den mest effektive løsning var derfor ikke flere hænder, men færre samtidige initiativer, tydeligere prioritering og mindre organisatorisk friktion.
Det illustrerer et generelt princip inden for Lean og flowbaseret udvikling: Den største gevinst findes sjældent ved at få mennesker til at arbejde hurtigere. Den findes ved at reducere ventetid, begrænse afhængigheder og skabe et mere jævnt flow gennem organisationen. Det er netop derfor, målinger som Lead Time og Flow Efficiency ofte siger mere om organisationens modenhed end klassiske produktivitetsmål.
Det betyder ikke, at alle organisationer skal bruge de samme KPI’er. Tværtimod. En startup med ét udviklingsteam har brug for et andet ledelsesoverblik end en international virksomhed med hundrede teams. Men princippet er det samme. KPI’er bør vælges ud fra de beslutninger, de skal understøtte ikke ud fra hvilke data der tilfældigvis er lettest at eksportere fra Azure DevOps eller Jira.
Når KPI’er fungerer bedst, bliver de ikke brugt til at kontrollere medarbejdere. De bliver brugt til at skabe fælles forståelse. De peger på, hvor organisationen mister kapacitet, hvor strategiske initiativer bliver forsinket, og hvor ledelsen selv kan gøre den største forskel. Det er her, data bliver til ledelse, og hvor dashboards udvikler sig fra at være rapportering til at blive et værktøj til bedre beslutninger.
Hos Empiric har vi samlet de KPI’er, vi oftest anbefaler softwareorganisationer, i et praktisk faktaark. Her beskriver vi ikke blot, hvad de enkelte KPI’er måler, men også hvordan de beregnes, hvor data typisk findes, og hvorfor de er relevante for ledelsen. Formålet er ikke at give alle organisationer de samme KPI’er, men at skabe et bedre udgangspunkt for den vigtigste diskussion af alle:
Måler vi det, der hjælper os med at levere mere værdi – eller måler vi blot det, der er nemmest at tælle?
