Hur mäter man egentligen hur effektiv en verksamhet är? Det är ingen lätt fråga, och många aldrig så välmenta försök har gått snett.
De flesta som utvecklar mjukvara håller idag med om att det inte är så lyckat att använda antal rader kod som ett mått på hur mycket man åstadkommit. Ett team som anses effektivare om de skriver många rader programkod löper stor risk att börja driva mot uppsvälld klipp-och-klistra kod, särskilt om någon skulle få för sig att koppla ett ekonomiskt incitament till modellen.
Vår bransch är inte ensam om att ha problem med att styra med mätmål. Svenska polisen har blivit omskriven för hur fokuset på antalet gjorda utblåsningstest leder till att man maximerar antalet test, men minimerar antalet stoppade rattfyllerister.
Risken när man väljer att mäta, följa upp och belöna en specifik sak är alltså att man får precis det man ber om: ett totalt fokus på den och bara den saken.
Dagens scrumtips är därför: var försiktig med vad du mäter, du kan få det.
Kommentarer
Misstaget som görs om och om igen är att tro att måttrymden har en god och en ond ände. T ex att många rader kod är bättre än få rader kod. Eller att få ärenden i buggarkivet är bättre än många ärenden i buggarkivet. Eller att många timmar spenderade på arbetsplatsen (gärna under obekväma arbetstider som kvällar och helger) är bättre än färre timmar spenderade på arbetsplatsen.
Vad är då alternativen? Ja det finns ytterligare två DÅLIGA alternativ:
1) Att vända på skalan: få rader kod är bättre än många etc.
2) Att inte mäta alls.
Men det finns också ett bra alternativ: Mät kontinuerligt flera saker utan att explicit värdera de i samband med att de mäts. Inga grattismejl med CC till alla VP när någon saknar tilldelade ärenden i buggarkivet och inga hjältesagor om killen som praktiskt taget bor på arbetsplatsen.
Vad ska man ha mätdata till? Två bra saker:
1) Samkör mätningarna och försök i efterhand hitta korrelationer. T ex: när kodtäckningen ökade så minskade antalet nya ärenden. Det är i så fall fakta om just vårt projekt, vår produkt, vårt team och vårt företag. Inte någon generell sanning som vi har hört på stan.
2) Analysera vilka mätdata som förändrades samtidigt som vi upplevde att det började gå signifikant bättre eller sämre för projektet.
Använd mått som är ENKLA, gärna automatiska, att samla in som kodrader eller kodtäckning. Det finns också många mått på kodkomplexitet som t ex cyklomatisk komplexitet, Ca, Ce, PDC m.m. Och det kan även vara mer processorienterade mått som t ex hur många möten vi har, hur långa iterationer vi har eller antal stories vi väljer att planera in i en iteration. Samband mellan sådana här olika kategorier kan hjälpa oss mycket i vår självförbättringsprocess.