"Retro är överflödigt": 7 tips på hur du ska reagera

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 ditt teams mognadsgrad – i detta sammanhang och även i allmänhet? Här är 7 tankar, 7 tips som hjälper dig med denna utmaning.

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 Mastern uppmuntrar Scrum Teamet att förbättra sin utvecklingsprocess och sina metoder inom ramen för Scrum-processen för att göra den mer effektiv och trevlig för nästa Sprint.”

I teorin innebär detta att retrospektivet bör vara en central händelse för Scrum Mastern, eftersom huvudsyftet med retrospektivet är att hjälpa teamet att kontinuerligt förbättra sig. I praktiken kanske teamet dock inte har den mognadsgrad som krävs för att verkligen dra nytta av ett retrospektiv och ser därför inte dess värde. Av denna anledning tolkar jag personligen uttalandet “göra teamet mer effektivt” på en abstrakt nivå som “öka teamets mognadsgrad”. Hur kan man göra det i detta sammanhang? Innan vi börjar med tipsen om detta, en förklaring till 🙂

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 man vill mäta den agila mognadsgraden - då bör man använda kvaliteten på retrospektiv som en indikator. Detta är det tidstypiska sambandet mellan “upplevd kvalitet på retrospektivet” och “Agil mognadsgrad” hos 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 %E2%80%9D, som spelar en annan roll i detta ämne.

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 plocka ut den här personen, förstå deras synvinkel och i bästa fall utforma motåtgärderna tillsammans med dem (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 genomföra retrospektivet. Låt oss säga att teamet helt enkelt behöver mer tid för att nå sitt sprintmål - och en timmes kodning istället för retro kan vara avgörande. I det här fallet är det okej att skjuta upp retrospektivet med 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

Det man inte mäter kan man inte ändra. En enkel och snabb vana som hjälper dig att kontinuerligt utvärdera hur teamet uppfattar retrospektiven är att mäta ROTI-poängen: Värdet “Return on time invest”. 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 väl investerad var tiden för detta retrospektiv?”. Mät genomsnittet över tid - förhoppningsvis kan du snart se en positiv trend!

Det genomsnittliga “Return-on-time-invest”-resultatet på en skala från 0 till 10 per månad i Echometer Tool - är retrospektiven värda det? Det verkar så!

4. Håll din sprint-retrospektiv mycket kort

Utvecklingsteamet anser alltså att sprintretrospektivet är överflödigt - vad ska du som Scrum Master göra nu?

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 retrospektiven har de uppenbarligen “lärt sig” att ROTI för ett retrospektiv - alltså kvaliteten på den investerade tiden, se ovan - är ganska dålig. Det finns ett ganska enkelt sätt att ändra detta: att helt enkelt investera mindre tid med samma resultat 🙂

Det är kanske det bästa tipset om teamet anser att sprintretrospektivet är överflödigt. Säg till ditt team: Okej, vi kommer att hålla det så kort som möjligt (mer om detta i vårt blogginlägg “ Kort tillbakablick - 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 tiden. Och du låter längden på retrospektivet växa “organiskt”, genom en “pull” eller “önskan” från teamet, för någon gång kommer det att vilja ha mer tid för retrospektivet. Hur gör man det? 

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

“Varför lyckades vi inte slutföra alla User Stories som fastställdes 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 strök några Dailies? Vet du vad som skulle hända? Eventuellt kommer det kanske inte att ha någon effekt - perfekt, då kan ni lika gärna behålla det så 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

Ett tillvägagångssätt som kan komplettera de andra tillvägagångssätten ä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 retrospektiven har varit 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: Ni inser hur mycket ni har förbättrat er under tiden. Kanske kan detta tillvägagångssätt för “kontinuerlig förbättring” faktiskt fungera?! Och retrospektiven kan faktiskt ha spelat en stor roll i detta. Rätt använt kan detta verkligen leda till ett aha-ögonblick 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 .

7. skapa mer variation i ditt retrospektiv

Ett av de typiska svaren på frågan “Utvecklingsteamet tycker att sprintretrospektivet är överflödigt - vad ska Scrum Mastern göra?” är att göra retrospektivet mer produktivt och spännande genom att införa mer variation i dina metoder och göra dem roligare. Jag betonar alltid att “kul” inte är så viktigt, fokus bör fortfarande ligga på att göra dem produktiva. Ändå kan kul naturligtvis utlösa en viss kreativitet och motivation. 

Detta innebär å ena sidan att du kan använda kreativa retrospektiva metoder - se t.ex. vårt inlägg om 32 Retrospektiva metoder för nybörjare och proffs -, dvs. metaforer i form av öppna frågor som väcker nya tankar och idéer.

Å andra sidan kan du också använda metoder som går längre än den typiska retrospektiven men som ändå syftar till att förbättra teamet. Du kan till exempel genomföra en retrospektiv/teamworkshop som fokuserar på psykologisk säkerhet i teamet förbättras - en av kärnförutsättningarna för framgångsrika team. 

Eller så använder du vårt retroverktyg Echometer, som kontinuerligt kompletterar din retrospektiv med vetenskapligt underbyggda frågor. De hjälper teamet att reflektera över i vilken utsträckning det uppfyller kärnegenskaperna hos framgångsrika team. Här är ett exempel på en av frågorna från vårt verktyg, ytterligare en förutsättning för framgångsrika team - en sund feedbackkultur:

Jag får regelbundet användbar feedback om hur bra jag presterar och hur jag kan förbättra mig.

Exempel på en impuls från Echometer-verktyget som diskuterats i retrospektiv.

Det finns många andra sätt att få variation i dina retros - var kreativ. 

Som sagt, beroende på “varför” teamet tycker att sprintretrospektivet är överflödigt, bör mer variation förmodligen inte vara den enda åtgärden för att lösa problemet.

Slutsats om “överflödiga retros”

Som du har sett tar de 7 tipsen och åtgärderna itu med utmaningen på olika nivåer. Om jag bara skulle ge ett tips skulle det vara att förkorta retrospektiven på ett intelligent sätt, som jag har beskrivit ovan. Om du kombinerar alla dessa åtgärder kommer du säkert att se resultat mycket snart. 

Ha kul med din 1TP17Continuous Improvement!