Så undviker du dåliga mätetal inom mjukvaruutveckling

Vad är poängen med mätetal?

Vilka resultat vill vi uppnå? Hur mäter vi framgång? Möjligheterna är obegränsade, och det är inte självklart vilka mätetal som är bra att följa upp.

Ett bra mätetal mäter något värdefullt och ger dig information som gör det möjligt att agera för att skapa värde. Ett mätetal som du inte kan agera på är däremot bara ett fåfängt mätetal.

Det finns gott om dåliga mätetal, och de kan ha allvarliga nackdelar, till exempel:

• De mäter något som inte är relevant för värdeskapandet

• De påverkar teamets motivation negativt

• De går att manipulera

Mät inte fel saker

Mätetal kopplade till årliga prestationsbedömningar och ekonomiska bonusar är till exempel vanliga. Det kan leda till att mål bestäms 1–1,5 år i förväg och sedan låses – och vi vet alla att det är uppenbart absurt i en agil värld.

Ett låst bonusupplägg minskar teamets agilitet. Teamet kanske vet att det finns något mer värdefullt att arbeta med, men arbetar i stället – helt rationellt – med det som står i bonusplanen.

Det vore mycket bättre om teamets prestationsbonusar kopplades till de faktiska affärsresultaten för produkten som teamet bidrar till.

Döda inte teamets motivation

När ett team vet att ett mätetal saknar mening blir teamet mer demotiverat ju mer uppmärksamhet ledningen ägnar åt det. Ett bra mätetal uppmuntrar, det motverkar inte.

Sluta manipulera mätetalen!

Dåliga mätetal är lätta att manipulera eftersom de uppmuntrar teamet att göra saker som får mätetalen att se bra ut. Saker som skulle skapa mer värde hamnar åt sidan. Teamet kanske till och med slutar fundera på vad som skapar värde och fokuserar enbart på det som mäts, oavsett hur fånigt det är.

Om vi till exempel mäter hur många fel som har åtgärdats, kommer många fel att åtgärdas.

Är det dåligt? Kanske inte direkt, men tänk på följande scenarier:

• Tänk om teamet instinktivt börjar rapportera många små fel som är enkla att åtgärda? Är det mest värdefulla sättet att använda teamets tid att åtgärda dessa små fel?

• Vad händer med fel som kräver mer utredning eller större insatser för att åtgärda? Arbetar teamet mer motvilligt med dem? Slutar teamet instinktivt att hitta sådana fel?

• Försöker teamet verkligen skapa lösningar med färre fel?

Exempel på dåliga mätetal

Här är några mätetal som kan verka rimliga vid första anblick, men som bör undvikas. För vissa ger jag även alternativa sätt att mäta de resultat du vill uppnå.

Ändringar i specifikationen

Om du börjar mäta hur många gånger en specifikation, eller beskrivningen av ett epic, har ändrats – vilken information ger det dig? Säger ett stort antal ändringar att teamet förfinar specifikationen utifrån kundfeedback eller prototyper?

Eller säger det bara att den ursprungliga specifikationen var usel från början?

Ett bra mätetal mäter något värdefullt eller en aktivitet som leder till värde. När någon börjar mäta ändringar i specifikationen kan vi anta att de vill se hur väl specifikationen ”utvecklas”. Det är dock ett dåligt mätetal eftersom det lätt kan misstolkas.

Låt oss titta på de aktiviteter som leder till bra (och värdefulla) arbetsdefinitioner:

• Idéarbete

• Identifiera osäkerheter och testa dem

• Få kundfeedback eller beteendedata tidigt

• Förfina arbetsdefinitionerna före den slutliga implementeringen

• Arbeta i tillräckligt små delar

• Continuous Delivery till produktion

• Följa upp funktionen i produktion

Det är svårt att se hur antalet ändringar i specifikationen någonsin skulle kunna spegla hur väl teamet gör dessa saker. 

Antalet ändringar är också ett enkelt mätetal att manipulera. Ändra bara en punkt, spara, ändra sedan en annan liten sak, spara …

Vilket mätetal skulle vara mer användbart för att mäta hur väl ett team reagerar på feedback? Jag har några i åtanke: 

• Antal marknadsnära tester per vecka

• Tid för att få statistiskt signifikanta resultat från marknadstester (dagar)

Kodändringar (code churn)

Det är svårt att veta om mängden kodändringar är bra eller dålig.

Det bra:

• Teamet får feedback på en prototyp, demo eller release och beslutar att ändra implementeringen.

• Teamet refaktoriserar kontinuerligt implementeringen för att möta aktuella och framtida behov.

Det dåliga: 

• Den tidiga specifikationen och förfiningen av funktionen var så bristfällig att implementeringen ständigt behöver ändras under utvecklingen.

• Bristfällig testning leder till omfattande omarbete sent i releasecykeln eller efter releasen.

Att enbart mäta antalet ändringar ger oss ingen värdefull information och kan också manipuleras. Det är helt enkelt ett dåligt mätetal.

Antal commits

När du börjar mäta hur många commits en utvecklare gör, vad är det egentligen du mäter? 

Syftet med det här måttet kan vara att motivera utvecklarna att checka in sina ändringar i små omgångar i stället för stora. Men måttet är mycket lätt att manipulera, vilket uppmuntrar utvecklarna att göra väldigt små, kontinuerliga incheckningar. Måttet tappar snabbt sitt värde och är därför ett dåligt mått.

Testtäckning för enhetstester

Enhetstester behövs, men vilken täckningsgrad är rätt? 100 %? Eller 80 %? Eller är egentligen alla procenttal ett dåligt mått? Läs den här roliga berättelsen om testtäckning för enhetstester.

Om du börjar mäta testtäckning för enhetstester kan teamets fokus lätt hamna fel. En bättre fråga är: vilka tester behövs verkligen, och vet utvecklarna hur man bygger effektiva enhetstester och har de en rutin för det som en del av Definition of Done?

Velocity

Velocity är ett bra mått för ett team, men bara för att hjälpa teamet att avgöra en rimlig nivå på sitt arbetsåtagande. Velocity blir ett bristfälligt mått om teamet eller ledningen börjar använda det som underlag för jämförelser.

Anledningen till att mäta velocity är att avgöra hur mycket arbete som ska tas in i en sprint. Dessutom kan Product Owner använda velocity-värdet för att uppskatta när något i produktbackloggen blir klart, eller när omfattningen för en release är klar, med ett release burnup-diagram. 

Att jämföra team med varandra utifrån velocity-värden är en usel idé: det kan vara ett av de största Agile-misstag ledningen kan göra. Team kan inte jämföras med varandra med hjälp av velocity-värden. Velocity bygger på uppskattningar av arbetsinsatsen före arbetet påbörjas, och de påverkas av många faktorer. Om sådana jämförelser inleds blir måttet genast föremål för omfattande manipulation, och en del av fördelarna går förlorade.

Ledningen bör i stället erbjuda hjälp så att teamen kan hitta den optimala nivån för investeringar i refinement och förplanering. Många team är stressade och pressade att leverera. Därför lägger de för lite tid på att förfina backloggen. Läs mer om backlog refinement i det här tidigare blogginlägget.

Team bör inte heller jämföra med sin egen velocity-historik. När teamet blir bättre eller effektivare uppskattar det arbetsinsatsen för ett arbete lägre än tidigare – velocity justeras automatiskt för förändringar som "vi är bättre nu".

Lika dåliga mått är "Story Points per utvecklare" eller "Story Points per timme". Den här typen av mått bör helt enkelt undvikas.

Rader kod

Om du mäter hur många rader kod utvecklarna producerar kommer de sannolikt att skriva fler rader kod än du behöver. 

Tänk efter: Vill du ha mer kod eller bättre kod? Vad bör kodgranskningen bidra med i mjukvaruutvecklingen? Ska andra utvecklare fundera på sätt att ytterligare öka mängden kod? Att mäta rader kod är helt enkelt dumt. 

Att mäta LoC är också ett dåligt mått eftersom det är lätt att manipulera. Även om man vänder på målet – och försöker skriva så lite kod som möjligt, med ambitionen att skapa en så enkel och elegant implementation som möjligt – kommer det sannolikt också att slå fel.

Timmar som läggs på en uppgift (eller tid på kontoret)

Agile-team bör uppskatta arbetsinsatsen innan de påbörjar arbetet. Det är grunden för velocity och bör vara måttet som teamet använder för att bedöma sitt åtagande för sprinten. Men arbetet med en uppgift bör inte mätas efter att det har påbörjats. 

När en uppgift har prioriterats tillräckligt högt för att tas med i sprinten bör teamet slutföra den tills den är klar. Det innebär att alla tester och acceptanskriterier uppfylls, att Product Owner godkänner den och att den har demonstrerats samt fått kundfeedback. Hur mycket arbetsinsats som läggs på den bör inte spela någon roll.

Arbetsuppgifter som passerar filtret Definition of Ready bör vara tillräckligt små för att inte kunna växa till månader av arbete – om det ändå händer är det ett sällsynt undantag. Product Owner känner förstås till det och kan avgöra om uppgiften fortfarande ger en god avkastning på investeringen.

Att logga timmar på en uppgift har bara nackdelar:

• Det kan få utvecklaren att tänka att saken väl måste vara klar när det uppskattade antalet timmar har lagts ner?

• Att lägga mindre tid än uppskattat känns fel, och utvecklaren kan överarbeta implementationen.

• Att lägga mer tid än beräknat väcker frågor utanför teamet – varför händer detta? Är du så dålig på ditt jobb att du måste lägga mer tid än vad som först uppskattades på uppgiften?

Lösning: mät inte nedlagda timmar alls, utan säkerställ bara att du inte påbörjar för stora uppgifter genom att använda Definition of Ready.

Jag har också hört skräckhistorier om företag som ibland mäter "tid på jobbet". Som om närvaro på kontoret automatiskt skulle leda till resultat med högt värde. Jag tycker att det vore mindre vansinnigt att mäta "antal koppar kaffe som dricks på jobbet" än "antal timmar på kontoret". Kaffekoppar skulle åtminstone kunna indikera möjligheter till socialt umgänge under fikapausen, vilket vanligtvis är en värdefull aktivitet!

Ett utmärkt exempel på hur dåligt (eller rentav galet) det är att mäta nedlagd tid: ge en tonåring uppgiften ”klippa gräsmattan” och börja mäta hur lång tid det tar. När du klipper gräsmattan tar det 1,5 timmar. Hur länge ska vi då vänta innan tonåringen förmodligen är klar? Två timmar? Fyra? Titta på detta och avgör själv.

Lösta ärenden eller åtgärdade buggar

Det här låter som ett bra mått. Men att mäta hur många buggar du har åtgärdat leder lätt till att teamet rapporterar många lättfixade buggar. Det uppmuntrar egentligen inte till bra kvalitetsarbete tidigare i processen för att undvika att buggarna uppstår från början, eller hur?

Vad du kan göra om din organisation använder tveksamma mått

Att mäta komplexa sociotekniska processer som mjukvaruutveckling är en komplicerad uppgift. Det är lätt att missa och utesluta vissa sociala aspekter och skapa ett mått som gör mer skada än nytta. Om du mäter fel saker kan ledningens uppmärksamhet och press stjälpa snarare än hjälpa.

Om du misstänker att du inte mäter rätt saker är det bäst att teamet funderar ordentligt på följande:

• Varför använder ni ett visst mått?

• Vilken information vill ni få fram, och varför är den värdefull?

• Vilken typ av mått skulle vara mer motiverande, mindre lätt att manipulera och mäta en mängd eller aktivitet som skapar värde?

När ni överväger alternativa mått, tänk på att bra mått:

• Ger värdefull information

• Mäter aktiviteter som vi vet leder till bra resultat

• Hjälper team att se om de rör sig i rätt eller fel riktning

• Hjälper till att upptäcka problem

Era utmaningar och problem förblir inte desamma, utan förändras. På samma sätt bör också era mått förändras. En framgångsrik organisation tänker igenom och omprövar vilka mått som är mest värdefulla vid varje given tidpunkt.

Eficode kan hjälpa dig att utforma och införa bättre mått för effektivare produktutveckling – kontakta oss gärna så går vi igenom era mått och hjälper er att definiera bättre.