Photo by Michael Held on Unsplash

Kom godt i gang med metrikker

“Det er meget fint alt sammen, men virker det og kan I bevise det?!”

Nogenlunde sådan siger mange ledere ofte til deres medarbejdere når hverdagen for det agile team har indfundet sig, og hvis du gerne vil kunne svare, “Ja da!”, så læs videre og bliv klogere på hvordan du kan komme hurtigt i gang med at bruge metrikker. Og hvis du er leder, så læs også videre og bliv klogere på hvordan du kan inspirere dine medarbejdere til at komme hurtigt i gang med struktureret kvantificering af deres performance.

Naturlig modstand
Når nogen efterspørger håndgribelige tal på team performance, så er det ganske logisk og helt fair fordi man ikke bør indføre agile for agiles skyld, men for at opnå et eller andet. Hvad enten det er øget kundetilfredshed, større arbejdsglæde, øget eksekveringsevne eller noget helt fjerde, så bør der i mine øjne altid foregå en systematisk kvantitativ måling af teamets performance.

Alligevel oplever jeg meget tit modstand overfor indførelsen af disse målinger fra Scrum Mastere og teammedlemmer. Som oftest er de usikre på hvad ledelsen mon bruger tallene til, og om de bliver brugt på en fair måde. Man vil jo nødigt fremstå svag til næste MUS samtale eller opleve at man selv knokler og andre i teamet ikke gør, for er det så retfærdigt at blive målt med i en samlet performancemåling af teamet?

Hvorfor bruge metrikker?
Lad mig slå fast med det samme: Når det agile team anvender metrikker er det først og fremmest for teamets egen skyld! Jeg plejer at kalde det for temaets instrumentbræt. Hvis man vil optimere sin kørsel i en bil, bliver man da nødt til at vide hvor hurtigt man kører og ved hvor mange omdrejninger, hvad temperaturen i og udenfor motoren er, hvor meget benzin der er i tanken, om GPSen viser at man er på rette vej osv. Uden et instrumentbræt kører man jo fuldstændig i blinde og hvordan pokker skulle man så kunne optimere sin kørsel?

For den agile leder er metrikkerne også et vigtigt instrument, når status quo skal udfordres og der skal ledes efter mulige tiltag for at forbedre rammerne for teamets performance. Udsving i metrikkerne er ofte et glimrende håndgribeligt udgangspunkt for at diskutere netop dette. Hvis en agil leder slår teams eller medarbejdere i hovedet med dårlige tal, eller måler en Scrum Master på stigningen i velocity, mangler pågældende leder en helt fundamental forståelse for Agile! Og så skal man starte et helt andet sted (det har vi i Ugilic i øvrigt et god bud på. Læs mere om Ugilics lederudvikling her: ugilic.dk/lederudvikling).

Retningslinjer
Jeg plejer også at formidle følgende enkle budskaber i forbindelse med indførelse af metrikker:

  • Brug metrikker til løbende forbedringer i teamet – ikke til at pege fingre
  • Brug metrikker til at identificere trends i værdi, velocity, kvalitet og effektivitet over tid – ikke til umiddelbar sammenligning af teams
  • Lad temas selv tilvælge egne metrikker til identificering af team performance
  • Det koster at måle
  • Mål kun hvad I er villige til at ændre
  • Alle metrikker kan manipuleres
  • Når man måler påvirker man resultatet

Startpakken
Jeg foreslår nedenstående startpakke for alle agile teams. Disse metrikker er enkle og hurtige at indsamle, og over tid kan de give en rigtig god indikator på teamets performance. Senere kan pakken udvides, og der er tonsvis af inspiration at hente på nettet. I øvrigt: lad Scrum Masteren eller den procesansvarlige sørge for at indsamle og formidle resultaterne (put det evt. i Excel). Når tallene skal analyseres, så se gerne på om der er en sammenhæng, fx mellem Velocity og arbejdsglæde, eller mellem gennemløbstid og kundetilfredshed.

Velocity
Nok den mest kendte metrik, i hvert fald i Scrum. Hvor mange story points kan teamet levere i et Sprint (eller en kadence for et Kanban teams vedkommende)? Og hvad der er mindst lige så interessant: Hvad er forskellen mellem hvad teamet planlagde og hvad man rent faktisk leverede?
Selvom teamet kan kan have en ambition om at opnå en stigning i velocity, er det mest normale at søge at stabilisere sin velocity og minimere forskellen mellem planlagte og leverede story points.

Arbejdsglæde
Start på den mest enkle måde: Ved hver afslutning på et Sprint eller en kadence scorer alle teammedlemmer deres arbejdsglæde fra 1-5 hvor 5 er højest. Husk at vurdere arbejdsglæden generelt over hele sprintet og abstrahér fra evt. gode eller dårlige enkeltstående oplevelser (fx på selve dagen for målingen). Jeg har mange gange blot bedt teamets medlemmer om at række en hånd i vejret og talt antallet af fingre. Det er hurtig gjort, og bagefter kan vi så stille det oplagte spørgsmål: Hvorfor har vi denne score, og hvad kan vi (eller vores leder) så gøre ved det?

Gennemløbstid
Hvor lang tid tager det at få kørende software igennem maskineriet? Man kan måle tiden fra et ønske ankommer til backlog’en og til det er leveret (antal dage er mest oplagte enhed), eller man kan måle fra den dag arbejdet påbegyndes til den dag det er leveret. Man skal blot være konsekvent og bruge måleresultatet til at starte en reel diskussion i teamet om hvor og hvordan man kan forbedre resultatet.

Kundetilfredshed
For rigtig mange af de agile teams jeg møder, er slutbrugeren eller “kunden” næsten uendelig langt væk. Og andre gange er teamets kunder andre medarbejdere/afdelinger i virksomheden (dvs. forbavsende tæt på). For mange virker det faktisk lidt unormalt og næsten grænseoverskridende at udpege 10-15 personer og jævnligt (fx efter hver Sprint Review eller kadence) spørge om de vil svare på følgende enkle spørgsmål: “På en skala fra 1-10, hvor 10 er højest, i hvor høj grad vil du så anbefale leverancen fra Team X til en ven eller kollega?” (kaldes også for Net Promotor Score). Men det bør helt ærligt ikke være så svært, og vil med garanti give interessante input til teamet.
Og pas på med at gøre det for omstændigt! Undgå online spørgskemaer og anden automatik, for så kan det kollidere med andre allerede etablerede dataindsamlinger i virksomheden. Send en mail, gå fordi og hils på eller spørg på Sprint review. Med andre ord: Keep it simple!

Afsluttende bemærkninger
Jeg håber at ovenstående har inspireret til at komme i gang med at bruge metrikker for både ledere og medarbejdere. Hvis du har spørgsmål eller kommentarer hører jeg meget gerne fra dig i kommentarfeltet herunder.

Skriver om problemstillinger for medarbejdere og ledere i agile transformationer.

Skriv en kommentar