"Retro er overflødig": 7 tips til hvordan du kan reagere

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å.

Hva kan du gjøre for å forbedre teamets modenhet – i denne sammenhengen og generelt? Her er 7 tanker, 7 tips som vil 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 sin utviklingsprosess og sine praksiser innenfor rammen av Scrum-prosessen, for å gjøre den mer effektiv og hyggelig for neste sprint.”

I teorien betyr dette at retrospektivet bør være en sentral hendelse for Scrum Master, siden hovedformålet med retrospektivet er å hjelpe teamet med å kontinuerlig forbedre seg. I praksis har imidlertid teamet kanskje ikke modenheten til å virkelig dra nytte av et retrospektiv, og ser derfor ikke verdien av det. Av denne grunn tolker jeg personlig utsagnet “gjøre teamet mer effektivt” på et abstrakt nivå som “øke teamets modenhet”. Hvordan kan man gjøre det i denne sammenhengen? Før vi begynner med tipsene om dette, en liten 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 man ønsker å måle den agile modenheten – bør man bruke kvaliteten på retrospektiver som en indikator. Dette er den tidsmessige typiske sammenhengen mellom «opplevd kvalitet på retrospektivet» og «Agil modenhet» til 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 %E2%80%9D, 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 er det en “opinionsleder” i teamet som har stor innflytelse på teamet. Prøv å plukke ut denne personen, forstå deres synspunkt og i beste fall utforme mottiltakene sammen med dem (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 gjennomføre retrospektivet. La oss si at teamet bare trenger mer tid for å nå sprintmålet sitt – og en times koding i stedet for retro kan være avgjørende. I dette tilfellet er det greit å utsette retrospektivet med 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

Det du ikke måler, kan du ikke endre. En enkel og rask vane som hjelper deg med å kontinuerlig vurdere hvordan teamet oppfatter retrospektivene, er å måle ROTI-scoren: Verdien av “Return on time invest”. Still ganske enkelt følgende spørsmål etter hvert retrospektiv, kanskje som en utsjekking: “På en skala fra 0 til 10, hvor godt var tiden investert for dette retrospektivet?”. Mål gjennomsnittet over tid – forhåpentligvis kan du snart se en positiv trend!

Den gjennomsnittlige “Return-on-time-invest”-scoren på en skala fra 0 til 10 per måned i Echometer Tool – er retrospektivene verdt det? Det ser slik ut!

4. Hold sprint-retrospektivet svært kort.

Utviklingsteamet synes altså at sprintretrospektivet 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-en til et retrospektiv – altså kvaliteten på den investerte tiden, se ovenfor – er ganske dårlig. Det finnes en ganske enkel tilnærming for å endre dette: å investere mindre tid med samme resultat 🙂

Dette er kanskje det beste tipset hvis teamet synes sprintretrospektivet er overflødig. Si til teamet ditt: Ok, vi skal holde det så kort som mulig (mer om det i blogginnlegget vårt “ Kort tilbakeblikk - 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 tiden. Og du lar lengden på retrospektivet vokse “organisk”, gjennom et “pull” eller “ønske” fra teamet, for på et tidspunkt vil det ønske seg 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 ble satt for den siste iterasjonen?”

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 om dere for eksempel dropper noen Dailies? Vet du hva som ville skje? Kanskje vil det ikke ha noen innvirkning – perfekt, da kan dere like gjerne fortsette slik 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 retrospektivene har vært 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: Dere innser hvor mye dere har forbedret dere i mellomtiden. Kanskje kan denne tilnærmingen til “kontinuerlig forbedring” faktisk fungere?! Og retrospektivene kan faktisk ha spilt en stor rolle i dette. Riktig brukt kan dette føre til en aha-opplevelse 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 .

7. Få mer variasjon i retrospektivet ditt

Et av de typiske svarene på spørsmålet “Utviklingsteamet synes sprintretrospektivet er unødvendig - hva skal Scrum Master gjøre?” er å gjøre retrospektivet mer produktivt og spennende ved å bringe mer variasjon inn i metodene dine og gjøre dem mer underholdende. Jeg understreker alltid at “moro” ikke er så viktig, fokuset bør fortsatt være på å gjøre dem produktive. Likevel kan moro selvfølgelig utløse en viss kreativitet og motivasjon. 

Det betyr på den ene siden at du kan bruke kreative retrospektive metoder - se f.eks. vårt innlegg om 32 Retrospektive metoder for nybegynnere og profesjonelle -, dvs. metaforer i form av åpne spørsmål som utløser nye tanker og ideer.

På den annen side kan du også bruke metoder som går utover det typiske retrospektivet, men som likevel har som mål å forbedre teamet. Du kan for eksempel gjennomføre en retrospektiv/teamworkshop som fokuserer på psykologisk sikkerhet forbedret i teamet - en av kjerneforutsetningene for vellykkede team. 

Eller du kan bruke vårt retro-verktøy Echometer, som kontinuerlig supplerer retrospektivet ditt med vitenskapelig begrunnede spørsmål. De hjelper teamet med å reflektere over i hvilken grad det oppfyller kjerneegenskapene til vellykkede team. Her er et eksempel på et av spørsmålene fra verktøyet vårt, en annen forutsetning for vellykkede team - en sunn tilbakemeldingskultur:

Jeg får jevnlig nyttige tilbakemeldinger om hvor godt jeg presterer og hvordan jeg kan forbedre meg.

Eksempel på en impuls fra Echometer-verktøyet som ble diskutert i retrospektivene.

Det finnes mange andre måter å bringe variasjon inn i dine retros - vær kreativ. 

Som sagt, avhengig av “hvorfor” teamet synes sprintretrospektivet er unødvendig, bør mer variasjon sannsynligvis ikke være den eneste tiltaket for å løse problemet.

Konklusjon om “unødvendige retrospektiver”

Som du har sett, tar de 7 tipsene og tiltakene for seg utfordringen på ulike nivåer. Hvis jeg bare skulle gi ett tips, ville det være å forkorte retrospektivet på en intelligent måte, slik jeg har skissert ovenfor. Hvis du kombinerer alle disse tiltakene, vil du helt sikkert se resultater veldig snart. 

Ha det gøy med din #kontinuerlige forbedring!