Retrospectives – you're doing it completely wrong – del 3/3

Jeg har faciliteret retrospectives i nogle år nu og også hen af vejen holdt oplæg om dem, både til folk, der syntes ideen er genial, og til folk, der synes den er tåbelig. De sidstnævnte er naturligvis de hårdeste, men måske også de sjoveste at holde oplæg for. De vil nemlig have svar på spørgsmål, de undrer sig, og det er første skridt til at lære noget nyt. Jeg er ofte hørt retrospectives beskrevet som spild af tid. Grunden kan være at man mener man kunne komme frem til det samme ved at sidde og snakke i kantinen, eller at man alligevel ikke ændrer sin opførsel, heller ikke selvom man angiveligt er nået frem til noget man gerne ville gøre anderledes. Lad os tage fat i det sidste først. Det er nemlig også noget Esther Derby, en af forfatterne til Agile retrospectives, er stødt på, som beskrevet i denne blog post fra hende.

Illustration: Privatfoto

Ret kort kan det siges, at hvis man til et retrospective udelukkende fokuserer på symptomerne og aldrig kommer frem til årsagerne, så er det klart at man gang på gang møder det samme problem og at det ikke bliver løst. Det er både frustrerende fordi man ikke synes man bliver klogere, men også fordi man snakker om det samme hele tiden til sine retrospectives. Det bliver de kedelige af og det føles som spild af tid.
På forskellige Scrum kurser, blandt andet Certified Scrum Master kurset (i hvert fald da jeg tog det) lærer man hvordan man kan facilitere et retrospective, f.eks. ved at se på hvad der gik godt, hvad der gik skidt og samle ideer til at gøre det anderledes.

Alt i alt et godt råd, desværre virker det ikke. Der er nogle der følger de udemærkede tanker omkring at facilitere retrospectives og faktisk bruger tid på at finde årsagerne til de symptomer man ser dukke op i softwareudvikling, men mange bruger det de måtte have lært eller hørt og går direkte til problemer og løsninger. Og hvad er der så galt med det, kunne man spørge? Intetsomhelst, hvis det faktisk er problemerne man har fat i og de rigtige løsninger man finder. Desværre er det ikke så nemt som det ser ud. Og hvis vi gennemgår faserne i et retrospective, som jeg har beskrevet her kan man ret tydeligt forklare hvorfor.

For det første kan der opstå den situation at ikke alle faktisk deltager i at finde frem til problemerne, og det kan der være flere grunde til. De føler sig usikre, de tror ikke at der faktisk er mulighed for at ændre noget, de mener ikke det er deres problem, etc. Dette kan afdækkes, og ofte afhjælpes, i den første del af et retrospective; Set the stage.

For det andet antages det meget ofte at alle kender alle data eller at alle har samme oplevelse af de hændelser der er sket. Dataindsamling skal være objektiv og alt hvad alle mener er relevant for dette retrospective skal med. Lidt ligesom at bruge “den hvide hat” i de Bonos seks tænkehatte. Dette finder sted i andel del af et retrospective; Gather Data

For det tredje kan man, ved at skynde sig at finde løsninger på de umiddelbare problemer risikere at man “løser” symptomerne i stedet for problemerne. Man finder de egentlige årsager til problemerne i det tredje skridt, også kaldet Generate Insights.

For det fjerde får man ikke lavet beslutninger som folk er enige om er en god ide, man får ikke en tilstrækkelig kritisk masse af folk til at ville lægge energi i eksperimenterne, og dermed udebliver ændringerne. Derfor er fjerde del vigtig; Decide what to do.

For det femte skal tiden overholdes, et retrospective skal ikke gå over tiden og det skal afsluttes korrekt med en kort gennemgang af hvad der er sket og hvad der skal ske nu. Gerne også med en aftale om hvornår det næste afholdes. Så husk at bruge tid på End the retrospective.

Konsekvensen af at udelade et (eller flere) af de fem dele af et retrospective er at man ikke får ret meget ud af sine retrospectives, at man hele tiden ser de samme problemer dukke op, at det er de forkerte beslutninger der tages, og at der ikke bliver fulgt op på beslutningerne. I sidste ende bliver retrospectives til spild af tid og enten kedelige eller pinlige.

Nu, hvor du har læst det hele kan jeg røbe at du bare kunne have set denne (http://www.infoq.com/presentations/Retrospectives-A-Bit-of-Ceremony-Can-...) ☺
Men det kan da være at du har en erfaring med retrospectives, der modbeviser det, og i så fald vil jeg gerne høre mere?

Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Aino Vonge Corry

Det er helt klart gammel vin på nye flasker, hvilket jeg også slog på tromme for i første del af indlægget. Nu har det så, som så meget andet med den agile verdens terminologiglæde, fået et nyt navn.
Sjovt nok er der bred enighed i facilitatorverdenen om at "retrospectives" er et dårligt navn, men nu hænger det ligesom ved...
Nye forslag er f.eks. futurespectives, lessons learned, etc.

  • 2
  • 1
Morten Fordsmand

I gamle dage kaldte man det "lessons learned" hvilket gjorde det helt klart hvad målet var.

I min terminologi er "retrospectives" noget fjernsyn og kunstmuseer laver når de ikke har nogen bedre ideer til at fylde tiden ud.


Måske er du bare ved at blive gammel; kendetegnet ved at kunne gennemskue at det nye med den smart betegnelse måske grundlæggende ikke er så nyt.

I øvrigt betyder "retrospective" vel bare tilbageskuende

  • 0
  • 1
Log ind eller Opret konto for at kommentere