Många menar att retrospektivet är den viktigaste ceremonin i den agila verktygslådan. Woody Zuill uttrycker det på följande sätt: 

Om du bara introducerar en #agile-rutin bör det vara retrospektiv. Allt annat kommer att följa.

Woody Zuill

Så varför är det ens möjligt för ett utvecklingsteam att anse att sprint retrospective är överflödigt? Enligt min erfarenhet som Scrum Master och psykolog har detta oftast att göra med teamets mognadsnivå.

Så vad kan du göra för att förbättra mognaden hos ditt team – i det här sammanhanget och i allmänhet? Här är 7 tankar och 7 tips som kan hjälpa dig med den här utmaningen.

Teamet tycker att retrospektiven är överflödig: vad ska man göra?

Förresten, det officiella svaret enligt Scrum-certifieringsexamen är detta: Scrum Master bör arbeta med teamet för att göra det mer effektivt. Mh, det hjälper inte riktigt. Vad kan man mena med det?

Scrum Master bör arbeta med teamet för att göra det mer effektivt

Den officiella rollen för en Scrum Master är följande, om du tittar på Scrum-guide tittar på: "Scrum Master uppmuntrar Scrum Team att förbättra sin utvecklingsprocess och praxis inom Scrum-processen för att göra den mer effektiv och njutbar för nästa Sprint."

I teorin innebär detta att retrospektivet bör vara en central händelse för Scrum Master, eftersom det huvudsakliga syftet med retrospektivet är att hjälpa teamet att kontinuerligt förbättra sig. Men i praktiken kanske teamet inte har den mognadsnivå som krävs för att verkligen använda en retrospektiv och därför kanske inte ser dess värde. Av den anledningen tolkar jag personligen påståendet "göra teamet mer effektivt" på en abstrakt nivå som "öka teamets mognadsnivå". Hur kan man göra det i det här sammanhanget? Innan vi börjar med tipsen om detta, ytterligare en förklaring

Retro anses vara värdefullt när man faktiskt förbättras kontinuerligt. Då är känslan av autonomi, självorganisering och self-efficacy hög. Vilket leder till hypotesen: Den upplevda kvaliteten på retrospektiver är en av de bästa indikatorerna för ett teams (agila) mognadsnivå. 

Om du vill mäta den agila mognadsnivån – bör du använda kvaliteten på retrospektiven som en indikator. Detta är den typiska korrelationen i tid mellan "upplevd kvalitet på retrospektivet" och "Agilem mognadsnivå" för ett team.

Denna utveckling uppnås på följande sätt: 

1. De första retros genomförs, åtgärder skrivs ner. Känslan infinner sig: Äntligen händer det något! 
2. Åtgärderna genomförs inte på riktigt. Det är mycket prat, men lite verkstad. 
3. Efter en tid uppstår frustration eller helt enkelt den så kallade "retro-fatigue". Nu uppstår fenomenet med denna artikel: Retrospektivet ses som överflödigt. Teamet självt uppfattar sig som relativt moget och ser inga problem.
4. Denna punkt nås endast av ett fåtal team. Nämligen när kvaliteten på retros ökar igen och det i slutändan leder till märkbara förbättringar och därmed känslan av self-efficacy långsamt mognar. 

Förhoppningsvis kommer tipsen i denna text att hjälpa dig att ta några steg i denna riktning. Men jag kan också varmt rekommendera vår text om "7 tips för bra åtgärdspunkter", som spelar en annan roll i denna fråga.

1. förstå varför teamet anser att en retrospektiv är onödig

Som Scrum Master kan du ha en hypotes om varför teamet tycker att sprint retrospective är onödigt. Men var snäll och testa denna hypotes. Fråga teamet uttryckligen om bakgrunden.

Ofta finns det en "opinionsledare" i teamet som har ett stort inflytande på teamet. Försök att identifiera denna person, förstå hans eller hennes synvinkel och i bästa fall utforma motåtgärder tillsammans med honom eller henne (se nedan).

Ju bättre du förstår teamet, desto bättre kan du utveckla en plan för att öka teamets mognad och välja det lämpligaste av följande tips.

2. utföra den retrospektiva

Du bör i princip göra retrospektiven. Låt oss säga att teamet bara behöver mer tid för att nå sitt sprintmål – och att en timmes kodning istället för retrospektivet kan vara avgörande. I så fall är det OK att skjuta upp retrospektiven i några dagar.

Du kan också ändra retrospektivets karaktär, göra det kortare och så vidare. Men det bästa sättet att visa teamet värdet av en retrospektiv är att ha en riktigt bra retrospektiv. Så min uppmaning är att se till att reservera en lucka i teamets kalender för retrospektivet.

3. mäta ROTI-värdet

Du kan inte förändra det du inte mäter. En enkel och snabb vana som hjälper dig att kontinuerligt bedöma hur teamet uppfattar retrospekterna är att mäta ROTI-poängen: värdet för "avkastning på investerad tid". Ställ helt enkelt följande fråga efter varje retrospektiv, kanske som en check-out: "På en skala från 0 till 10, hur bra var den investerade tiden för detta retrospektiv?". Mät genomsnittet över tid – och förhoppningsvis kommer du snart att se en positiv trend!

Den genomsnittliga "return-on-time-invest" poäng på en skala från 0 till 10 per månad i Echometer verktyg – är retros värt det? Det verkar så!

4. Håll din sprint-retrospektiv mycket kort

Så utvecklingsteamet tycker att sprint retrospective är överflödigt – vad ska du göra nu som Scrum Master?

Som jag nämnde i början tycker teamet förmodligen att en sprint-retrospektiv inte är nödvändig eftersom de tycker att det är slöseri med tid.

Med andra ord: I de senaste retrospektiverna har de tydligen "lärt sig" att ROTI för en retrospektiv –, dvs. kvaliteten på den investerade tiden, se ovan –, är ganska dålig. Det finns en ganska enkel metod för att ändra på detta: investera helt enkelt mindre tid för samma resultat.

Det här är kanske det bästa tipset om teamet tycker att sprintretrospektiven är onödig. Säg till ditt team: OK, vi kommer att hålla det så kort som möjligt (läs mer i vårt blogginlägg "Kort retrospektiv – Bättre snabbt än inte alls"). 

Viktigt: Du vill inte signalera att det kommer att förbli så här för alltid. Ditt budskap förblir detsamma: Retrospektiver är verkligen viktiga. Förr eller senare kommer retrospektiverna inte längre att vara så korta.

Men du förkortar retrospektivet (t.ex. från 60 minuter till 30 minuter) eftersom teamet på så sätt lär sig hur viktigt det kan vara att investera tid. Och du låter längden på retrospektiven växa "organiskt", så att säga, genom en "pull" eller "önskan" från teamet, eftersom de vid något tillfälle kommer att vilja ha mer tid för retrospektiven. Hur gör man då? 

Du ställer helt enkelt den viktigaste frågan:

"Varför lyckades vi inte slutföra alla användarberättelser som fastställts för den senaste iterationen?"

Detta kommer att leda till intensiva diskussioner och förmodligen idéer till åtgärder på kort tid. Det kan även leda till längre diskussioner. Och teamet har redan signalerat att de behöver mer tid för en retrospektiv (naturligtvis är det ditt jobb att hålla diskussionen konstruktiv).

Du bör alltid ställa den fråga som du tror kommer att väcka bra tankar eller diskussioner i teamet. Och du bör alltid ha som mål att registrera ett experiment som du kommer att prova under nästa sprint (även känt som en åtgärdspunkt).

5. föreslå att även andra rutiner utelämnas

Så teamet tycker att en retrospektiv är slöseri med tid. Okej, då. Som Scrum Master bör ditt huvudmål aldrig vara att vara den person som implementerar Scrum. Nej, det handlar inte om "Scrum". 

Det handlar om att teamet ska vara framgångsrikt och leverera värde till kunden och intressenterna. Scrum är tänkt att hjälpa teamet att göra det. Men det är bara ett ramverk, en verktygslåda (en ganska bra sådan) med många möjliga tillvägagångssätt för att leverera värde snabbt, hållbart och med hög kvalitet.

Så om teamet är missnöjt med retros, kan du betona att du ser på Scrum ur det perspektiv som just beskrivits. Och sedan kan du tillägga att du tycker att några av de andra rutinerna ni har faktiskt är mindre viktiga än retrospektivet. 

Retrospektiven är motorn för kontinuerlig förbättring. Den är tänkt att hjälpa teammedlemmarna att ta reda på vad som fungerade bra och vad som inte gjorde det. Om du utelämnar den här delen av den kontinuerliga förbättringsloopen riskerar du att den stannar upp.

 

Vad skulle till exempel hända om ni utelämnade några dagstidningar? Vet du vad som skulle hända? Det kanske inte har någon inverkan – perfekt, då kan du hålla det på samma sätt och spara tid. 

Å andra sidan kan detta också leda till sämre kommunikation i teamet. Teamet gör därför misstag. I slutändan kommer det att finnas ett organiskt behov av mer kommunikation, vilket du skulle märka vsl. i retrospektiv. Den här gången introduceras dock inte en agil ceremoni på grund av din insisterande, utan på grund av teamets "smärta". Som ett resultat kommer det att finnas mycket mer acceptans för denna ceremoni i teamet.

6. titta på tidigare retrospektiver och visa deras värde

En metod som kan komplettera de andra metoderna är att titta på teamets "retrospektiva historia" över en längre tidsperiod. Förutsättningen för detta är att några av de senaste retrospektiverna var framgångsrika.

Du tittar till exempel på tillbakablicken från ett år sedan och inser hur svåra dessa utmaningar var förra året. Och sedan inser man att det skulle vara så mycket enklare att lösa samma utmaningar idag om man hade all den kunskap och erfarenhet som man har samlat på sig.

Med andra ord: Du inser hur mycket du har förbättrats under tiden. Kanske kan denna metod för "kontinuerlig förbättring" fungera trots allt?! Och retrospektiven kan verkligen ha spelat en stor roll i detta. Om de används på rätt sätt kan de verkligen leda till en aha-upplevelse i teamet.

Dessutom kan du också titta på ROTI-värdet (avkastning på tidsinvestering) för din senaste retrospektiv (se ovan): Om du kan bevisa att retrospektivet har en ROTI på 8 till 10 är tiden uppenbarligen väl investerad. Vårt retrospektivverktyg Echometer, till exempel, frågar efter ROTI efter varje retrospektiv och ger dig därmed en regelbunden indikator på den relevanta prestandan. Din prestation som Scrum Master.