En personlig tolkning av Scrumguidens syfte med Retrospektiv

carita_tsiantes_inceptive.png

Efter några års arbete som Scrum master så inser jag att jag har skapat min egna tolkning om hur man utför vissa Scrumaktiviteter. Detta inlägg kommer beskriva varför jag skapat min egna strategi när det gäller att få så givande Retrospektiv som möjligt.

 

Enligt Scrumguiden så står det att Retrospektivet syfte är att:

  1. Granska hur den senaste sprinten gick med tanke på personer, relationer, processer och verktyg;

  2. Identifiera och ordna de större sakerna som gick bra samt möjliga förbättringar;

  3. Skapa en plan för att införa förbättringar i Scrumteamets arbetssätt.

Det är ju en bra strategi när man tittar lite snabbt, det verkar vara ett enkelt sätt att ge ett fokus för teamet som de kan ta med in i nästa sprint. Däremot så tror jag tyvärr att punkt #2 skadar mer än vad den hjälper och tar onödig tid.

Varför skadar det då?

Grundproblemet är att det står ingenstans att man måste välja ett visst antal ärenden i listan. Men många Scrum masters tolkar detta så, vilket gör att istället för att bara få en prioriterad lista så väljs många ärenden bort för att de inte uppfattas lika högprioriterade av majoriteten av teamet.  

Jag har ännu inte träffat på ett team där ”alla jobbar med allt” så min erfarenhet är att det finns personer som känner sig lite utanför det ”vanliga teamet”. Detta händer oftast med de som har specialistområden men kan såklart även ske pga. andra orsaker.

Min tolkning av Scrumguiden kommer från att om en person redan känner sig lite utanför och får sedan sitt ”problem” bortprioriterat så är risken ganska hög att hen kommer känna sig ännu mer utanför och följdaktningsvis så kommer personen tappa engagemanget gentemot teamet och sitt arbete. För att inte tala om att teamet även kommer förlora viktig input från de som sitter mer ensamma inom olika fokusområden. Så mitt mål är att skapa en struktur för teamet som istället ökar känslan av gemenskap och senare även ökar engagemanget.

Jag tror på att man bygger ett starkt team utifrån att stärka varje individ. Så även om jag förstår att man kan tycka att teamet inte ska lägga för många timmar på att lösa ett problem så säger min erfarenhet att det är viktigare för teamkänslan att skapa en Action Point på alla problem för att visa alla teammedlemmar att deras enskilda åsikt är viktig och betydelsefull.

Så här kommer ”Söndra och härska” in i leken. För ibland så kan problem vara för stora för att förstå, så min riktlinje är att skapa en AP som är estimerad till max 1 timme. Sen planeras detta ärende in till nästkommande sprint för att vid dess Retrospektiv se över om problemet är löst eller om det krävs en ny AP.

Så mitt syfte med Retrospektivet har blivit följande:

  1. Granska de förbättringsåtgärder som var planerade för den aktuella sprinten. Behöver någon mer AP göras eller är problemet löst?  

  2. Granska hur den senaste sprinten gick med tanke på personer, relationer, processer och verktyg

  3. Identifiera och skapa förbättringsåtgärder på de saker som gick bra och de upplevda hindren under sprinten. En förbättringsåtgärd bör vara på max 1 timme.

  4. För in förbättringsåtgärderna i nästkommande sprintbacklogg.

Förutom att denna taktik skapar mer engagemang inom teamet så är det två onödiga delar som försvinner:

  1. Man slösar inte tid på att komma fram till vad som är viktigast utan kan lägga tid på att hitta lösningar istället.

  2. Man slipper höra om samma problem (som inte blir omhändertaget) gång på gång på gång…

Resultatet av denna strategi har varit givande genom åren. I början så kommer det finnas flera problem att hantera. Det brukar däremot ebba ut efter ett tag och teamet har samtidigt lärt sig att det är allas ansvar att föra fram problem och ta fram förbättringsåtgärder som ett viktigt steg för att skapa ett självorganiserande team!

/ Carita Jansson Tsiantes 

 

Magnus WillnerComment