"Retro er overflødigt": 7 tips til, hvordan du skal reagere

Mange siger, at retrospektivet er den vigtigste ceremoni i den agile værktøjskasse. Woody Zuill udtrykker det på denne måde: 

Hvis du kun introducerer #agile praksis, så bør det være retrospektiver. Alt andet vil følge efter.

Woody Zuill

Så hvorfor er det overhovedet muligt for et udviklingsteam at betragte sprintretrospektivet som overflødigt? Min erfaring som Scrum Master og psykolog er, at det som regel har noget at gøre med teamets modenhedsniveau.

Hvad kan du så gøre for at forbedre dit teams modenhed – i denne sammenhæng og generelt? Her er 7 tanker, 7 tips, der vil hjælpe dig med denne udfordring.

Teamet synes, at retrospektivet er overflødigt: Hvad gør man?

I øvrigt er det officielle svar ifølge Scrum-certificeringseksamen dette: Scrum Masteren skal arbejde på teamet for at gøre det mere effektivt. Mh, det hjælper ikke rigtig. Hvad kan der menes med det?

Scrum Masteren bør arbejde med teamet for at gøre det mere effektivt.

Den officielle rolle for en Scrum Master er som følger, hvis du ser på Scrum-guide kigger på: “Scrum Masteren opmuntrer Scrum Teamet til at forbedre sin udviklingsproces og sine metoder som en del af Scrum processen for at gøre den mere effektiv og behagelig for den næste sprint.”

I teorien betyder det, at retrospektivet bør være en central begivenhed for Scrum Masteren, da hovedformålet med retrospektivet er at hjælpe teamet med løbende at forbedre sig. I praksis har teamet måske ikke den modenhed, der skal til for virkelig at udnytte et retrospektiv, og derfor ser de ikke værdien af det. Derfor fortolker jeg personligt udsagnet “gøre teamet mere effektivt” på et abstrakt niveau som “øge teamets modenhed”. Hvordan kan man gøre det i denne sammenhæng? Før vi starter med tipsene til dette, er der lige en forklaring 🙂

Retro betragtes som værdifuldt, når man faktisk forbedrer sig løbende. Så er følelsen af autonomi, selvorganisering og self-efficacy høj. Hvilket fører til hypotesen: Den opfattede kvalitet af retrospektiver er en af de bedste indikatorer for et teams (agile) modenhedsniveau. 

Hvis man ønsker at måle den agile modenhed - så bør man bruge kvaliteten af retrospektiver som en indikator. Dette er den typiske tidsmæssige sammenhæng mellem “opfattet kvalitet af retrospektivet” og et teams “agile modenhed”.

Denne progression opnås på følgende måde: 

1. De første retros bliver udført, foranstaltninger bliver skrevet ned. Følelsen opstår: Endelig sker der noget! 
2. Foranstaltningerne bliver ikke rigtig implementeret. Der er meget snak, men lidt handling. 
3. Efter et stykke tid opstår der frustration eller simpelthen den såkaldte “retro-træthed”. Nu opstår fænomenet i denne artikel: Retrospektivet bliver set som overflødigt. Teamet selv opfatter sig som relativt modent og ser ingen problemer.
4. Dette punkt nås kun af nogle få teams. Nemlig når kvaliteten af retroerne stiger igen, og det i sidste ende fører til mærkbare forbedringer, og dermed modnes følelsen af self-efficacy langsomt. 

Forhåbentlig vil tipsene i denne tekst hjælpe dig med at tage et par skridt i den retning. Men jeg kan også varmt anbefale vores tekst om “ 7 tips til gode handlingspunkter %E2%80%9D, som spiller en anden rolle i dette emne.

1. forstå, hvorfor teamet mener, at et retrospektiv er unødvendigt

Som Scrum Master har du måske en hypotese om, hvorfor teamet mener, at sprint retrospective er unødvendigt. Men test venligst denne hypotese. Spørg teamet eksplicit om baggrunden.

Ofte er der en “opinionsleder” i teamet, som har stor indflydelse på teamet. Prøv at udpege denne person, forstå deres synspunkt og i bedste fald udforme modforanstaltningerne sammen med dem (se nedenfor).

Jo bedre du forstår teamet, jo bedre kan du udvikle en plan for at øge teamets modenhed og vælge den mest hensigtsmæssige af de følgende tips.

2. udføre den retrospektive

Du bør som udgangspunkt gennemføre retrospektivet. Lad os antage, at teamet simpelthen har brug for mere tid til at nå deres sprintmål - og en times kodning i stedet for retro kunne være afgørende. I dette tilfælde er det okay at udskyde retrospektivet et par dage.

Du kan også ændre retrospektivets karakter, gøre det kortere og så videre. Men den bedste måde at vise teamet værdien af et retrospektiv på er at have et rigtig godt retrospektiv. Så min opfordring er, at du sørger for at reservere en plads i teamets kalender til retrospektivet.

3. Mål ROTI-værdien

Det, man ikke måler, kan man ikke ændre. En enkel og hurtig vane, der hjælper dig med løbende at vurdere, hvordan teamet opfatter retrospektiverne, er at måle ROTI-scoren: Værdien af “Return on time invest”. Stil blot følgende spørgsmål efter hvert retrospektiv, måske som et tjek: “På en skala fra 0 til 10, hvor godt var tiden investeret i dette retrospektiv?”. Mål gennemsnittet over tid - forhåbentlig kan du snart se en positiv tendens!

Den gennemsnitlige “Return-on-time-invest” score på en skala fra 0 til 10 pr. måned i Echometer Tool - er retrospektiverne det værd? Det ser sådan ud!

4. Hold dit sprint retrospective meget kort

Udviklingsteamet mener altså, at sprint retrospektivet er overflødigt - hvad skal du så gøre som Scrum Master?

Som jeg nævnte i begyndelsen, føler teamet sandsynligvis, at et sprint retrospective ikke er nødvendigt, fordi de synes, det er spild af tid.

Med andre ord: I de seneste retrospektiver har de tilsyneladende “lært”, at ROTI’en for et retrospektiv - altså kvaliteten af den investerede tid, se ovenfor - er ret dårlig. Der er en ret enkel tilgang til at ændre dette: simpelthen at investere mindre tid med samme output 🙂

Det er måske det bedste tip, hvis teamet mener, at sprint retrospektivet er overflødigt. Sig til dit team: Okay, vi vil holde det så kort som muligt (mere om det i vores blogindlæg “ Kort tilbageblik - hellere hurtigt end slet ikke ”). 

Vigtigt: Du ønsker ikke at signalere, at det vil forblive sådan for evigt. Dit budskab forbliver det samme: Retrospektiver er virkelig vigtige. Før eller siden vil retrospektiverne ikke længere være så korte.

Men du forkorter retrospektivet (f.eks. fra 60 minutter til 30 minutter), fordi teamet på den måde lærer, hvor vigtigt det kan være at investere tiden. Og du lader længden af retrospektivet vokse nærmest “organisk” gennem et “pull” eller “ønske” fra teamet, for på et tidspunkt vil det ønske mere tid til retrospektivet. Hvordan gør man det? 

Du stiller simpelthen det vigtigste spørgsmål:

“Hvorfor lykkedes det os ikke at færdiggøre alle de user stories, der var fastlagt for den sidste iteration?”

Det vil føre til nogle intense diskussioner og sandsynligvis ideer til handling på kort tid. Det kan endda føre til længere diskussioner. Og teamet har allerede signaleret, at de har brug for mere tid til et retrospektiv (det er selvfølgelig dit job at holde diskussionen konstruktiv).

Du bør altid stille det spørgsmål, som du tror, vil sætte gang i gode tanker eller diskussioner i teamet. Og du bør altid have som mål at registrere et eksperiment, som du vil afprøve i det næste sprint (også kendt som et action item).

5. foreslår også at udelade andre rutiner

Så teamet mener, at et retrospektiv er spild af tid. Okay, det er det. Som Scrum Master bør dit hovedmål aldrig være at være den person, der implementerer Scrum. Nej, det handler ikke om “Scrum”. 

Det handler om, at teamet skal have succes og levere værdi til kunden og interessenterne. Det er meningen, at Scrum skal hjælpe teamet med at gøre det. Men det er bare en ramme, en værktøjskasse (en ret god en) med mange mulige tilgange til at levere værdi hurtigt, bæredygtigt og med høj kvalitet.

Så hvis teamet er utilfredse i forhold til retros, kan du understrege, at du ser på Scrum ud fra det perspektiv, der lige er beskrevet. Og så kan man tilføje, at man synes, at nogle af de andre rutiner, man har, faktisk er mindre vigtige end retrospektivet. 

Retrospektivet er motoren til kontinuerlig forbedring. Det er meningen, at det skal hjælpe teammedlemmerne med at finde ud af, hvad der fungerede godt, og hvad der ikke gjorde. Hvis du udelader denne del af det kontinuerlige loop, risikerer du at sætte det kontinuerlige forbedringsloop i stå.

Hvad ville der for eksempel ske, hvis I udelod et par Dailies? Ved du, hvad der ville ske? Måske vil det slet ikke have nogen indflydelse - perfekt, så kan I lige så godt fortsætte med det og spare tid. 

På den anden side kan det også føre til dårligere kommunikation i teamet. Teamet begår derfor fejl. I sidste ende vil der være et organisk behov for mere kommunikation, som du ville bemærke vsl. i retrospektiv. Denne gang er en agil ceremoni dog ikke indført på din opfordring, men på grund af teamets “smerte”. Som et resultat vil der være meget mere accept af denne ceremoni i teamet.

6. se på tidligere retrospektiver og vise deres værdi

En tilgang, der kan supplere de andre tilgange, er at se på teamets “retrospektive historie” over en længere periode. Forudsætningen for dette er, at nogle af de seneste retrospektiver har været succesfulde.

For eksempel ser man på tilbageblikket fra for et år siden og indser, hvor svære de udfordringer var sidste år. Og så indser man, at det ville være så meget lettere at løse de samme udfordringer i dag, hvis man havde al den viden og erfaring, man har fået.

Med andre ord: I erkender, hvor meget I har forbedret jer i mellemtiden. Måske kunne denne tilgang til “kontinuerlig forbedring” alligevel fungere?! Og retrospektiverne kunne faktisk have spillet en stor rolle i det. Korrekt anvendt kan det godt føre til en aha-oplevelse i teamet.

Derudover kan du også se på ROTI-værdien (return on time investment) for dit sidste retrospektiv (se ovenfor): Hvis du kan bevise, at retrospektivet har en ROTI på 8 til 10, er tiden tydeligvis godt investeret. Vores retrospektive værktøj Echometer spørger f.eks. til ROTI efter hvert retrospektiv og giver dig dermed en regelmæssig indikator for den relevante performance. Din præstation som Scrum Master .

7. Bring mere variation ind i dit tilbageblik

Et af de typiske svar på spørgsmålet “Udviklingsteamet synes, at sprint-retrospektivet er overflødigt - hvad skal Scrum Master gøre?” er at gøre retrospektivet mere produktivt og spændende ved at bringe mere variation ind i dine metoder og gøre dem mere underholdende. Jeg understreger altid, at “sjov” ikke er så vigtig, fokus bør stadig være på at gøre dem produktive. Ikke desto mindre kan sjov selvfølgelig udløse en vis kreativitet og motivation. 

Det betyder på den ene side, at du kan bruge kreative retrospektive metoder - se f.eks. vores indlæg om 32 Retrospektive metoder for begyndere og professionelle -, dvs. metaforer i form af åbne spørgsmål, der sætter nye tanker og ideer i gang.

På den anden side kan du også bruge metoder, der går ud over det typiske retrospektiv, men stadig sigter mod at forbedre teamet. For eksempel kan du gennemføre en retrospektiv/teamworkshop, der fokuserer på psykologisk sikkerhed i teamet forbedret - en af de vigtigste forudsætninger for succesfulde teams. 

Eller du kan bruge vores retro-værktøj Echometer, der løbende supplerer dit retrospektiv med videnskabeligt baserede spørgsmål. De hjælper teamet med at reflektere over, i hvor høj grad det opfylder kerneegenskaberne for succesfulde teams. Her er et eksempel på et af spørgsmålene fra vores værktøj, en anden forudsætning for succesfulde teams - en sund feedback-kultur:

Jeg får regelmæssigt nyttig feedback om, hvor godt jeg klarer mig, og hvordan jeg kan forbedre mig.

Eksempel på en impuls fra Echometer-værktøjet, der blev diskuteret i retrospektiver.

Der er mange andre måder at bringe variation ind i dine retros - vær kreativ. 

Som sagt, afhængigt af “hvorfor” teamet synes, at sprint-retrospektivet er overflødigt, bør mere variation sandsynligvis ikke være den eneste foranstaltning til at løse problemet.

Konklusion om “overflødige retrospektiver”

Som du har set, adresserer de 7 tips og handlinger udfordringen på forskellige niveauer. Hvis jeg kun skulle give ét tip, ville det være at forkorte retrospektivet på en intelligent måde, som jeg har skitseret ovenfor. Hvis du kombinerer alle disse tiltag, vil du helt sikkert se resultater meget snart. 

God fornøjelse med din #-kontinuerlige forbedring!