Agile målinger er verktøy som benyttes for å overvåke fremdrift og suksess for et smidig prosjektteam.
Når disse målingene er definert på en hensiktsmessig måte, gir de innsikt i teamets prestasjoner, kvalitet på arbeidet, effektivitet av testing, og den generelle effektiviteten, samt hvordan dette utvikler seg over tid.
Det overordnede målet med smidige målinger er å bistå teamet med å identifisere områder som trenger forbedring, og å ta beslutninger basert på data som vil bidra til bedre produkter etter hvert som teamet utvikler seg.
Ofte ser vi at bedrifter definerer målinger som enten er forfengelighetsmålinger eller rene tall, som øker jevnt og trutt. Disse målingene kan se bra ut på et dashbord, men er vanligvis verdiløse for selve teamet.
Hensikten er ikke å hjelpe teamet på noen måte, men heller å generere rapporter for ledelsen for å deretter fatte strategiske beslutninger. Dessverre fører dette til at teamet ikke forstår hvorfor akkurat disse avgjørelsene tas.
I et forsøk på å tilfredsstille slike feilaktige målinger, manipulerer teamene sine egne prosesser for å få målingene til å se bra ut. Men resultatet for teamet blir ikke bedre i det hele tatt.
Grunnleggende målinger
Det finnes mange måter å kategorisere målinger på. En av de mest grunnleggende er topp-ned og bunn-opp.
➡️ Topp-ned innebærer: Ledelsen definerer målinger som teamet forventes å oppfylle, og målet er å havne i de «grønne» områdene. Det er irrelevant om teamet liker disse målingene eller ikke; dette er hva ledelsen ønsker å overvåke.
➡️ Bunn-opp betyr: Teamet identifiserer områder som må forbedres, og definerer målinger som lar dem spore fremgangen mot disse målene. Teamet kan deretter demonstrere for ledelsen hvordan deres arbeid har forbedret seg over tid.
Definisjon av en god metrikk
Hva kjennetegner en god måling, og hvordan beskriver vi den?
Den viktigste egenskapen er atferdsendring. Det betyr at når du ser på resultatene av en måling, skal det være klart hva teamet må endre for å oppnå forbedring.
En god måling skal også være enkel. Hvis du ikke kan forklare den med noen få enkle setninger slik at alle relevante parter forstår, er den ikke god nok.
En god måling er sammenlignbar over tid. Ta et øyeblikksbilde av resultatene på et gitt tidspunkt, og gjør det igjen senere. Sammenlign de to resultatene. Hvis du ikke kan sammenligne de to, bør du revurdere målingen.
Til slutt, i stedet for bare å se på rene tall, bør du, der det er mulig, bruke forhold eller prosentandeler. «10 nye åpne defekter i løpet av sprinten» sier ikke så mye. Det avhenger av om du vanligvis har 1 eller 100.
Her er noen eksempler på målinger som jeg mener oppfyller disse kriteriene. De er spesielt rettet mot smidige team, og er inndelt i tre hovedkategorier: Ytelse, kvalitet og moral.
Kategorier av målinger
Ytelsesmålinger
Målet er å forstå hvor godt teamet er til å gjennomføre planlagte oppgaver i en sprint. Dette vurderer om overengasjement er vanlig, eller om ufullførte oppgaver er standard fra sprint til sprint.
Fra et smidig perspektiv bør teamet streve etter å levere det sprintinnholdet de forpliktet seg til i begynnelsen av sprinten.
Dette betyr ikke at vi ikke skal være fleksible under sprinten. Men det skal alltid være en forhandling som fører til en endring, ikke bare en tilleggelse. Teamets kapasitet vil ikke øke bare fordi noen legger til nye oppgaver under sprinten.
Vi bruker denne målingen for å se etter slike tilfeller, og for å veilede alle i teamet til å beskytte kapasiteten de har for en sprint.
Dette bygger opp teamets pålitelighet og forutsigbarhet.
#1. Sprintkapasitet vs. leverte historiepoeng
Se på forholdet mellom sprintkapasitet og leverte historiepoeng (SP) over tid.
- Små avvik fra sprint til sprint er akseptabelt. Store variasjoner signaliserer at noe ikke er som det skal.
- Total sprintkapasitet beregnes ved å summere antall tilgjengelige dager for alle teammedlemmene. For eksempel, hvis teamet har 10 medlemmer som er tilgjengelige hele sprinten, er den totale kapasiteten 100.
Sammenlign sprintkapasiteten med fullførte SP fra sprint til sprint. Hvis teamet (under planleggingen) forplikter seg til en betydelig større mengde SP enn de vanligvis klarer å fullføre, øker dette risikoen for teamet.
Målet bør være å ha en planlagt SP som er lik eller mindre enn totalt fullført SP per sprint.
Du kan fortsatt ha flere fullførte SP enn planlagt, hvis teamet fullførte alle planlagte oppgaver, og fortsatt hadde kapasitet til å ta på seg mer.
- Hvis teamet gjentatte ganger leverer mindre SP enn planlagt, må de endre planleggingen og ta på seg færre SP i neste sprint.
Verktøy som monday.com, Atlassian Jira eller Asana tilbyr en enkel måte å lagre og hente ut historiepoeng for hver oppgave i en sprint. De kan også generere dette automatisk etter hver sprintplanlegging.
#2. Nedbrenningsdiagram
Dette er en måling som de fleste scrum-team sannsynligvis har liggende et sted på dashbordet. Det kan til og med virke unyttig å ha den. Teamet tar den sjelden i betraktning. Ledelsen liker derimot å påpeke hvordan oppgavene ser ut fra et overordnet nivå, og hvordan de ikke utvikler seg (ettersom de alle er åpne gjennom hele sprinten).
Jeg vil understreke at dere som team bør sjekke nedbrenningsdiagrammet for deres egen skyld. Hvis alle oppgaver er åpne gjennom hele sprinten, og først stenges på sprintens siste dag, skaper dette usikkerhet internt i teamet og i forhold til fullføring av sprintmålene.
- Gå gjennom sprinttavlen for fullførte oppgaver.
- Snakk med teamet for å finne ut hvorfor små oppgaver fortsatt er åpne, selv om de ble startet tidlig i sprinten.
- Jobb med teamet for å endre tankegangen slik at oppgaver ikke holdes åpne lenger enn nødvendig.
- Det ideelle nedbrenningsdiagrammet er vanligvis en teoretisk tilstand. Men jo nærmere vi kommer det, jo mer effektiv er oppgavehåndteringen.
Agile verktøy som Asana kan generere et nedbrenningsdiagram for deg automatisk for hver sprint.
Kilde: asana.com
#3. Fullføring av sprintmål
Dette måler prosentandelen av sprintmålene som ble fullført i løpet av hver sprint.
Sprintmålene dokumenteres separat, for eksempel på en Confluence-side eller i Jira, for hver sprint. Det skal være en status som viser om målene ble nådd eller ikke innenfor sprinten.
Selv om teamet ikke fullførte alle oppgavene i løpet av en sprint, kan de fortsatt ha oppnådd sprintmålet (f.eks. mangler bare mindre oppgaver).
Vi bør sikte på 100 % fullføring av sprintmål hver sprint. Hvis dette ikke er tilfelle, bør teamet finne ut hva som hindrer dem.
- Hvis det er for mange parallelle oppgaver i hver sprint, reduser antall oppgaver.
- Hvis det legges til for mange ad hoc-oppgaver i løpet av sprinten, reduser dette slik at det ikke påvirker de opprinnelige sprintmålene.
- Hvis sprintmålene er for store eller utfordrende, gjør dem enklere. Det gir uansett ingen mening å ha store sprintmål uten å oppfylle dem ved slutten av sprinten.
Kodekvalitetsmålinger
Dette skal måle hvor god koden er over tid. Det bidrar til å opprettholde sunne utviklingsprosesser og reduserer tiden som brukes på å løse problemer. Det reduserer også utviklernes inaktive tid som oppstår ved å vente på at kode skal kjøres under utviklings- og testaktiviteter.
Kilde: azuredevopslabs.com
#1. Automatiserte tester
Utviklerne lager automatiserte enhetstester for hver endring de gjør.
- Mål kodedekning ved hjelp av automatiserte tester – bruk Azure Pipelines eller SonarCloud for å kjøre testene. Sikt på 85 % dekning. Over 90 % er ikke særlig effektivt.
- Sørg for at automatiserte enhetstester er en del av definisjonen av «ferdig» for nye oppgaver.
- Ta igjen gammel kodetestdekning som en del av tekniske gjeldsoppgaver i backloggen.
#2. Kodekompleksitet
Vurder unødvendige komplikasjoner i koden over tid, og korriger dette aktivt ved hjelp av tekniske gjeldsoppgaver. Prøv også å forhindre at de oppstår hvis mulig.
Definer kodestandarder og retningslinjer for å lære utviklere å følge dem. Sørg for at de overholder kodingsreglene for å minimere unødvendig økning i kodekompleksitet. Oppdater retningslinjene regelmessig basert på teamets erfaringer.
Identifiser «kodestank» – indikatorer på potensielle problemer i koden, for eksempel duplisert kode, lange metoder og ubrukte variabler.
Fagfellevurderinger skal sikre at kodestandarder brukes på ny kode.
Bruk verktøy som Azure Ado eller SonarCloud dashbord og rapporter for å oppdage kodeproblemer.
#3. Manuelle trinn i distribusjon
Overvåk hvor mange manuelle trinn teamet må utføre for å frigi kode til test- eller produksjonsmiljøer.
- Målet er å nå 0 over tid.
- Lag tekniske gjeldsoppgaver om nødvendig for å automatisere distribusjons-/frigjøringspipelinen. Reduser gradvis de gjenværende manuelle trinnene i prosessene fra sprint til sprint.
Moralmålinger
Dette er en måling for å spore hvordan teamet føler om arbeidet sitt og prosessene de jobber med daglig.
#1. Oppfølging av sprint-retrospektiv
Du kan spore hvor mange av tiltakspunktene som faktisk ble gjennomført i neste sprint.
- Scrum Master samler resultatene av retrospektive møter på teamets sider for å spore avtalte tiltakspunkter.
- Teamet vil deretter overvåke fremdriften.
- Prosjektledelsen kan vurdere om tiltakspunktene utvikler seg eller hva som hindrer teamet i å fullføre dem. Endre deretter miljøet for å gjøre det mulig for teamet å komme videre med de avtalte tiltakspunktene.
Minst 33 % eller 1 (avhengig av hva som er høyest) av tiltakspunktene fra forrige sprint skal tas i bruk i de neste sprintene.
Hvis det er mindre enn dette, er det nødvendig med endringer for å la teamet implementere forbedringene de ble enige om.
Prosjektstyringsverktøy inneholder maler som er klare til bruk for retrospektive aktiviteter. Her er et eksempel fra monday.com:
Kilde: monday.com
#2. Teamsamarbeid
Spor parprogrammering.
- Opprett naturlige par per oppgave for å jobbe sammen, dele observasjoner, kunnskap og suksess. Lag underoppgaver under oppgaver som eies av forskjellige teammedlemmer.
Spor kodeanmeldelser fra fagfellers initiativ.
- Fagfeller blir bedt om eller tar initiativ til å gjennomgå andre sine resultater.
Målingene kan hentes fra monday.com/Asana/Jira-tavlen fra underoppgavene.
Minst 50 % av oppgavene i sprinten skal deles av teammedlemmer. Hvis det er mindre enn dette, undersøk årsakene og iverksett tiltak der det er fornuftig.
For frivillige fagfellevurderinger, spor oppgavene med dedikerte underoppgaver. I begynnelsen er 20 % av kodeoppgavene som gjennomgås på denne måten en god start. Over tid bør du oppmuntre teamet til å samarbeide mer, og øke det til 50 % av kodeoppgavene per sprint som et mål.
#3. Teknisk gjeld vs. nye funksjonalitetsoppgaver
Kilde: atlassian.com
Å gi teamet muligheten til å løse sine egne gjeldsoppgaver vil øke teamets tilfredshet med arbeidet.
- Akkumulering av teknisk gjeld uten en plan for å løse dem gradvis vil derimot demotivere teamet over tid. Og løsningen vil bli mer ustabil, kompleks og vanskelig å løse uten betydelig omarbeiding.
Teamet vet best hva som ikke fungerer bra med løsningen, selv om interessentene eller sluttbrukerne ikke ser det. Slike oppgaver har størst innvirkning på selve utviklerteamet. For interessentene kan de være usynlige. Derfor er det viktig å gi teamet sjansen til å jobbe med oppgaver som vil hjelpe dem å rydde opp i utviklingsaktivitetene.
Målet er å spore hvor mange tekniske gjeldsoppgaver som løses over tid, og om etterslepet av slike oppgaver bare vokser eller ikke.
Teamet kan merke oppgavene som «Teknisk gjeld» i backloggen, og prioritere dem fra teamet slik at de kan bli valgt ut i sprinter.
Avhengig av prosjektets status og mengden teknisk gjeld som er identifisert i backloggen, kan du sørge for at det tekniske gjelds-etterslepet ikke vokser med mer enn 10 % fra sprint til sprint.
Prioriter tekniske gjeldsoppgaver og inkluder dem i sprintene for å holde veksten av det tekniske gjelds-etterslepet under kontroll, slik at teamet får lov til å jobbe med tekniske gjeldsoppgaver 10–20 % av tiden hver sprint.
Avslutningsvis
Alle prosjekter vil etter hvert trenge noen målinger, enten fordi ledelsen ønsker det, eller fordi teamet bestemmer seg for å måle sin egen suksess.
Det beste du kan gjøre er å begynne å bygge et bibliotek med målinger som er klare til å bli tatt i bruk; jo før jo bedre. Og når du gjør dette, sørg for at du alltid prioriterer målinger som fremmer atferdsendring.
Deretter kan du se etter usunne prosesser som kan ødelegge sprinten.