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.

Så hvad kan du gøre for at forbedre modenheden af dit team – i denne sammenhæng og generelt? Her er 7 tanker, 7 tips, der kan 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 ser på: "Scrum Masteren opmuntrer Scrum-teamet til at forbedre deres udviklingsproces og praksis inden for Scrum-processen for at gøre den mere effektiv og fornøjelig til 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. Men i praksis har teamet måske ikke modenhedsniveauet til virkelig at bruge et retrospektiv og ser derfor ikke dets værdi. Derfor fortolker jeg personligt udsagnet "gør teamet mere effektivt" på et abstrakt niveau som "øg teamets modenhedsniveau". Hvordan kan man gøre det i denne sammenhæng? Før vi begynder med tipsene til dette, endnu 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 du vil måle det agile modenhedsniveau –, bør du bruge kvaliteten af retrospektiver som en indikator. Dette er det typiske tidsmæssige forhold mellem "opfattet kvalitet af retrospektivet" og "Agilem modenhedsniveau" for et team.

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", som spiller en anden rolle i dette spørgsmål.

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 finde frem til denne person, forstå hans eller hendes synspunkt og i bedste fald udvikle modforanstaltninger sammen med ham eller hende (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

I bund og grund bør du lave retrospektivet. Lad os sige, at teamet bare har brug for mere tid til at nå sit sprintmål –, og at en times kodning i stedet for retrospektivet kunne være afgørende. I dette tilfælde er det OK 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

Man kan ikke ændre det, man ikke måler. 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 "afkastet af den investerede tid". Stil blot følgende spørgsmål efter hvert retrospektiv, måske som et check-out: "På en skala fra 0 til 10, hvor god var den investerede tid til dette retrospektiv?". Mål gennemsnittet over tid – forhåbentlig vil 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-værktøjet – er retroerne det værd? Det ser sådan ud!

4. Hold dit sprint retrospective meget kort

Så udviklingsteamet mener, at sprintretrospektivet er overflødigt – hvad skal du nu 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 sidste retrospektiver har de tilsyneladende "lært", at ROTI for en retrospektiv –, dvs. kvaliteten af den investerede tid, se ovenfor –, er ret dårlig. Der er en ganske enkel måde at ændre dette på: Man investerer simpelthen mindre tid for det samme output.

Dette er måske det bedste tip, hvis teamet mener, at sprint retrospective er unødvendigt. Sig til dit team: OK, vi holder det så kort som muligt (læs mere i vores blogindlæg "Kort retrospektiv – 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 "organisk", så at sige, gennem et "pull" eller "ønske" fra teamet, fordi de på et tidspunkt vil ø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 brugerhistorier, vi havde sat 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 du udelod et par dagbøger? Ved du, hvad der ville ske? Måske vil det ikke have nogen indflydelse – perfekt, så kan du beholde det samme 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 sidste retrospektiver var vellykkede.

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: Du indser, hvor meget du har forbedret dig i mellemtiden. Måske kan denne "løbende forbedring"-tilgang alligevel fungere?! Og retrospektiverne kan faktisk have spillet en stor rolle i dette. Brugt korrekt kan det helt sikkert føre til et "aha"-øjeblik 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.