Fortsätt till huvudinnehåll

Som man mäter får man svar

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

Eller ännu bättre: "var försiktig med hur du TOLKAR dina mätresultat".

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.
Tobias Fors sa…
Hej Staffan! Tack för dessa givande tips!

Populära inlägg i den här bloggen

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fu…

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.
En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida…