Mange sier at retrospektivet er den viktigste seremonien i den smidige verktøykassen. Woody Zuill sier det på denne måten: 

Hvis du bare innfører #agile-praksis, bør det være retrospektiver. Alt annet kommer etter hvert.

Woody Zuill

Så hvorfor er det i det hele tatt mulig for et utviklingsteam å anse sprintretrospektivet som overflødig? Min erfaring som Scrum Master og psykolog er at dette vanligvis har å gjøre med teamets modenhetsnivå.

Så hva kan du gjøre for å forbedre teamets modenhet – i denne sammenhengen og generelt? Her er 7 tanker og 7 tips som kan hjelpe deg med denne utfordringen.

Teamet mener at retrospektivet er overflødig: hva skal vi gjøre?

Det offisielle svaret i Scrum-sertifiseringseksamenen er for øvrig dette: Scrum Masteren bør jobbe med teamet for å gjøre det mer effektivt. Mh, det hjelper egentlig ikke. Hva kan menes med det?

Scrum Master bør jobbe med teamet for å gjøre det mer effektivt.

Den offisielle rollen til en Scrum Master er som følger, hvis du ser på Scrum-veiledning ser på: "Scrum Master oppmuntrer Scrum-teamet til å forbedre utviklingsprosessen og praksisen i Scrum-prosessen for å gjøre den mer effektiv og morsom i neste Sprint."

I teorien betyr dette at retrospektivet bør være en sentral hendelse for Scrum Master, ettersom hovedformålet med retrospektivet er å hjelpe teamet med å forbedre seg kontinuerlig. I praksis er det imidlertid ikke sikkert at teamet har det modenhetsnivået som kreves for å virkelig bruke retrospektivet, og derfor ikke ser verdien av det. Derfor tolker jeg personlig utsagnet "gjøre teamet mer effektivt" på et abstrakt nivå som "øke teamets modenhetsnivå". Hvordan kan du gjøre det i denne sammenhengen? Før vi begynner med tipsene om dette, en forklaring

Retro anses som verdifullt når man faktisk forbedrer seg kontinuerlig. Da er følelsen av autonomi, selvorganisering og mestringsfølelse høy. Noe som leder til hypotesen: Den opplevde kvaliteten på retrospektiver er en av de beste indikatorene for teamets (smidige) modenhetsnivå. 

Hvis du ønsker å måle det agile modenhetsnivået –, bør du bruke kvaliteten på retrospektivene som en indikator. Dette er det typiske tidsmessige forholdet mellom "opplevd kvalitet på retrospektivet" og "modenhetsnivå Agilem" i et team.

Denne progresjonen oppnås på følgende måte: 

1. De første retrosene gjennomføres, tiltak skrives ned. Følelsen oppstår: Endelig skjer det noe! 
2. Tiltakene er i realiteten ikke iverksatt. Det er mye snakk, men lite handling. 
3. Etter en tid oppstår frustrasjon eller rett og slett den såkalte "retro-fatigue". Nå oppstår fenomenet i denne artikkelen: Retrospektivet oppleves som overflødig. Teamet selv oppfatter seg som relativt modent og ser ingen problemer.
4. Dette punktet nås bare av noen få team. Det er nemlig når kvaliteten på retrosene øker igjen og til slutt fører til merkbare forbedringer, slik at mestringsfølelsen langsomt modnes. 

Forhåpentligvis vil tipsene i denne teksten hjelpe deg med å ta noen skritt i denne retningen. Jeg kan imidlertid også anbefale teksten vår om "7 tips til gode tiltak", som spiller en annen rolle i denne saken.

1. Forstå hvorfor teamet mener at et retrospektiv er unødvendig.

Som Scrum Master har du kanskje en hypotese om hvorfor teamet mener at sprintretrospektivet er unødvendig. Men vær så snill å teste denne hypotesen. Spør teamet eksplisitt om bakgrunnen.

Ofte finnes det en "opinionsleder" i teamet som har stor innflytelse på teamet. Prøv å finne frem til denne personen, forstå vedkommendes synspunkt og i beste fall utforme mottiltak sammen med vedkommende (se nedenfor).

Jo bedre du forstår teamet, desto bedre kan du utvikle en plan for å øke teamets modenhet og velge det mest hensiktsmessige av følgende tips.

2. gjennomføre den retrospektive

Du bør i utgangspunktet gjøre retrospektivet. La oss si at teamet bare trenger mer tid for å nå sprintmålet –, og at en times koding i stedet for retrospektivet kan være avgjørende. I så fall er det greit å utsette retrospektivet noen dager.

Du kan også endre innholdet i retrospektivet, gjøre det kortere og så videre. Men den beste måten å vise teamet verdien av et retrospektiv på, er å gjennomføre et virkelig godt retrospektiv. Så min oppfordring er å sette av tid i teamkalenderen til retrospektivet.

3. måle ROTI-verdien

Du kan ikke endre det du ikke måler. En enkel og rask vane som hjelper deg med å kontinuerlig vurdere hvordan teamet oppfatter retrospektivet, er å måle ROTI-poengsummen: "return on time invested"-verdien. Still ganske enkelt følgende spørsmål etter hvert retrospektiv, kanskje som en utsjekking: "På en skala fra 0 til 10, hvor mye tid ble investert i dette retrospektivet?". Mål gjennomsnittet over tid – og forhåpentligvis vil du snart se en positiv trend!

Gjennomsnittlig "return-on-time-invest"-poengsum på en skala fra 0 til 10 per måned i Echometer-verktøyet – er det verdt det? Det ser slik ut!

4. Hold sprint-retrospektivet svært kort.

Så utviklingsteamet mener at sprint-retrospektivet er overflødig – hva bør du som Scrum Master gjøre nå?

Som jeg nevnte innledningsvis, føler teamet sannsynligvis at et sprintretrospektiv ikke er nødvendig fordi de mener det er bortkastet tid.

Med andre ord: I de siste retrospektivene har de tilsynelatende "lært" at ROTI for en retrospektiv –, dvs. kvaliteten på den investerte tiden, er ganske dårlig. Det finnes en ganske enkel måte å endre dette på: rett og slett investere mindre tid for samme resultat.

Dette er kanskje det beste tipset hvis teamet mener at sprintretrospektivet er unødvendig. Si til teamet ditt: OK, vi holder det så kort som mulig (les mer i blogginnlegget vårt "Kort retrospektiv – Bedre raskt enn ikke i det hele tatt"). 

Viktig: Du ønsker ikke å signalisere at det vil forbli slik for alltid. Budskapet ditt forblir det samme: Retrospektiver er veldig viktige. Før eller senere vil retrospektivene ikke lenger være så korte.

Men du forkorter retrospektivet (f.eks. fra 60 minutter til 30 minutter) fordi teamet på denne måten lærer hvor viktig det kan være å investere tid. Og du lar lengden på retrospektivet vokse "organisk", så å si gjennom et "pull" eller "ønske" fra teamet, for på et eller annet tidspunkt vil de ønske mer tid til retrospektivet. Hvordan gjør man det? 

Du stiller ganske enkelt det viktigste spørsmålet:

"Hvorfor klarte vi ikke å fullføre alle brukerhistoriene som var satt for forrige iterasjon?"

Dette vil føre til intense diskusjoner og sannsynligvis ideer til tiltak i løpet av kort tid. Det kan til og med føre til lengre diskusjoner. Og teamet har allerede signalisert at de trenger mer tid til en retrospektiv (det er selvfølgelig din jobb å holde diskusjonen konstruktiv).

Du bør alltid stille det spørsmålet du tror vil sette i gang gode tanker eller diskusjoner i teamet. Og du bør alltid ha som mål å registrere et eksperiment som du vil prøve ut i neste sprint (også kjent som et action item).

5. foreslår at du også utelater andre rutiner.

Teamet mener altså at et retrospektiv er bortkastet tid. Det er greit. Som Scrum Master bør hovedmålet ditt aldri være å være den som implementerer Scrum. Nei, det handler ikke om "Scrum". 

Det handler om at teamet skal lykkes og levere verdi til kunden og interessentene. Scrum skal hjelpe teamet med å gjøre det. Men det er bare et rammeverk, en verktøykasse (en ganske god verktøykasse) med mange mulige tilnærminger for å levere verdi raskt, bærekraftig og med høy kvalitet.

Så hvis teamet er misfornøyd med retrospektivet, kan du understreke at du ser på Scrum ut fra det perspektivet som nettopp er beskrevet. Og så legger du til at du mener at noen av de andre rutinene dere har, faktisk er mindre viktige enn retrospektivet. 

Retrospektivet er motoren for kontinuerlig forbedring. Det skal hjelpe teammedlemmene med å finne ut hva som fungerte bra og hva som ikke fungerte. Hvis du utelater denne delen av den kontinuerlige forbedringssløyfen, risikerer du at den stopper opp.

 

Hva ville for eksempel skje hvis du utelot noen få dagbøker? Vet du hva som ville skje? Kanskje det ikke vil ha noen innvirkning – perfekt, da kan du beholde det samme og spare tid. 

På den annen side kan dette også føre til dårligere kommunikasjon i teamet. Teamet gjør derfor feil. Til slutt vil det være et organisk behov for mer kommunikasjon, noe du vil merke vsl. i retrospektiv. Denne gangen introduseres imidlertid ikke en smidig seremoni på grunn av din insistering, men på grunn av teamets "smerte". Som et resultat vil det være mye større aksept for denne seremonien i teamet.

6. Se på tidligere retrospektiver og vis verdien av dem.

En tilnærming som kan utfylle de andre tilnærmingene, er å se på teamets "retrospektive historie" over en lengre periode. Forutsetningen for dette er at noen av de siste retrospeksjonene var vellykkede.

Du ser for eksempel på tilbakeblikket for et år siden og innser hvor vanskelige utfordringene var i fjor. Og så innser du at det ville vært mye enklere å løse de samme utfordringene i dag hvis du hadde hatt all den kunnskapen og erfaringen du har opparbeidet deg.

Med andre ord: Du innser hvor mye du har forbedret deg i mellomtiden. Kanskje denne "kontinuerlig forbedring"-tilnærmingen kan fungere likevel?! Og retrospektivene kan faktisk ha spilt en stor rolle i dette. Brukt på riktig måte kan det absolutt føre til aha-opplevelser i teamet.

I tillegg kan du også se på ROTI-verdien (return on time investment) for det siste retrospektivet (se ovenfor): Hvis du kan bevise at retrospektivet har en ROTI på 8 til 10, er tiden åpenbart godt investert. Retrospektivverktøyet vårt, Echometer, spør for eksempel etter ROTI etter hvert retrospektiv, og gir deg dermed en jevnlig indikator på resultatene. Dine prestasjoner som Scrum Master.