Jimmy Janlén "Den Scrummande Konsulten"

På den gamla goda tiden gick det enkelt att ta reda på om det går bra eller dåligt för ett projekt. Hur många procent av kravlistan har vi bockat av? Hur stora (eller små) är avvikelserna från budget och deadlines? Samma frågeställningar fungerar inte tillfredställande i det agila projektet.

Vilka verktyg och mätvärden finns till hands när man jobbar agilt?

.

I ett agilt projekt finns det såklart oftast budget och deadlines men ingen detaljerad plan eller detaljerad kravlista att mäta avvikelser från. En av anledningarna till att man jobbar agilt är för att man insett att dessa måttstockar inte berättar något om hur bra produkt eller system man har byggt. Samt kommit till insikt om att planer bara är prognoser och inte något facit.

Detta betyder dock inte att vi ska sluta bry oss om hur bra eller dåligt ett Scrum-projekt går. En agil process som välkomnar förändringar och bygger på att skapar kunskap verkar dock slingra sig från att mätas. Vi måste ta till andra metoder och mätvärden än de vi kanske är vana med för att få en bra insyn i hur projektets sanna status är.

Först och främst borde vi förtydliga vad det är vi egentligen undrar när vi ställer oss frågan om ett projekt går bra? Kanske kan frågan styckas upp i följande, mer konkreta, frågeställningar:

1. Är alla stakeholders nöjda? Tycker beställaren han/hon fått valuta för sina pengar?
2. Upplever användaren att produkten/systemet är användbart och värdefullt?
3. Håller produkten/systemet hög teknisk kvalitet och är fritt från buggar?
4. Är systemet enkelt att förvalta/vidareutveckla?

.

Nedan listas förslag på mätvärden som kan användas för löpande utvärdering av ett projekts framgång och status och som beslutsunderlag under den löpande planeringen. I kommande artiklar (del 2-6) kommer jag beskriva var och en djupare och förklara vad dom syftar till och vad mätvärdet kan berätta om.

.

Agila mätvärden

.

Resultat
Projektets förmåga att göra stakeholders glada och leverera värdefull mjukvara enligt plan och prognoser…

• Release Plan vs. Effektmål / ROI
• Rest/Släp
• Driftsättnings-/Packeteringsinsats
• Risk Burndown
• Project Success Factors

.

Produktivitet
Teamets förmåga att produktivt bygga och leverera funktioner…

• Velocity – Trend
• Velocity – Förutsägbarhet
• Work In Progress
• Focus Factor/DRAG
• Time To Market

.

Kvalitet
Teamets förmåga att bygga kvalitativ mjukvara…

• Buggar i produktion
• Teknisk Skuld
• Rest/Släp

.

Teamets nivå
Mår man bra och är motiverad gör man ett bättre jobb…

• Agile/Scrum Mognadsgrad
• Teamets välbefinnande

.

”You want the truth? You can’t handle the truth!”

Man får dock inte luras att tro att det finns egenvärde i något av ovanstående mätvärden! Eller än värre, ge sig i kast med att försöka sub-optimera med hänsyn till ett enskilt värde.

Alla former av suboptimeringar har en tendens att slå tillbaka och försök att belöna (eller bestraffa) team eller individer baserat på valfritt mätvärde riskerar sabotera projektet och kommer med tiden undergräva teamets effektivitet, moral och förmåga att bygga kvalitativ mjukvara.

Innan ni i ert projekt börjar föra statistik och historik fråga er varför ni mäter X, vilket problem hoppas ni kunna lösa och hur resultatet ska användas.

.

Detta är del 1 av 6. Läs vidare:

Om att mäta det agila projektets framgång (1/6) – Introduktion

Om att mäta det agila projektets framgång (2/6) – Resultat

Om att mäta det agila projektets framgång (3/6) – Produktivitet

Om att mäta det agila projektets framgång (4/6) – Kvalitet

Om att mäta det agila projektets framgång (5/6) – Teamets nivå

Om att mäta det agila projektets framgång (6/6) – Agera på kunskap

(Länkarna uppdateras allteftersom artiklarna publiseras.)