Posted by: Carlos Buxton | Sep 24, 2010

What is it about retrospectives that scares us?

In all my experience as a PM and subsequently as an agile/scrum enthusiast (OK, I guess evangelist!), the most misunderstood and often most avoided element is the dreaded lessons learned or retrospectives. Is it an ingrained fear to face what went wrong that we hide behind excuses to not have them?

The essence of a retrospective is the same whether we are having ONE at the end of a project, or one at the end of each sprint: to inspect what has been done, analyze the good, the bad and the ugly (sorry Clint) and adapt so we can leverage that lesson next project or sprint. It is the essence of any agile framework a continuous cycle of inspection/adaptation.

I am guilty of not being a good retrospective facilitator, which is why I engage the experts I know to help me there. So in order to become more effective, I have been reading a book by Esther Derby and Diana Larsen(1).I must say I was wary of the “Retrospective Gods” titles given to the authors, but as I read the book, I find myself drawn by their approach and can almost feel in a room with them talking about the topic (which I would love to do at some point!).

We sometimes tend to shy away from hard lessons, but let’s remember that retrospectives is also about the positives that we have experienced in the past sprint and understanding how we can continue them in the next one.

Inspect/adapt, Inspect/adapt, Inspect/adapt – and let the team help you understand how to be more effective and productive!

 Footnotes:

1 Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen, foreword by Ken Schwaber (Click on the image below for more information)

Agile Retrospectives: Making Good Teams Great


Responses

  1. Hi, Carlos –

    I think the dread of retrospectives has two main sources:

    1) prior “lessons learned” or “post mortem” meetings that degenerated into blame-fests and witch hunts.

    2) prior LL, PM or retrospectives where there was lots of talk and no action.

    In agile retrospectives, I help the team choose actions that will improve their working environment and working relationships AND are within their control, or at least within their sphere of interest AND they have energy to work on.

    Often, when teams go after an ‘”important” problem, they are taking on an intrenched systemic problem. Those are usually beyond what the team can accomplish. So they loose energy and efficacy. And they begin to dread retrospectives.

    Esther

    • Hi Esther,
      Extremely good points!
      Retrospective findings and action items need to be actionable and implementable by the team for the team’s goals or we face the potential of having them classified as “all talk”.

      We have to be careful to differentiate among those suggestions that we can actually make happen versus those that fly in the face of company “culture”. Although changing what we think is broken can make a great crusade, it may not a battle we should undertake right now, or reasonable in duration. Those battles tend to be protracted and fought at a different level than the team, and fighting them, although potentially good in the long term (if we can implement the change), will probably side track the team’s focus and productivity.

      That is not to say that there may not be valuable lessons to document. It has been my experience that as we facilitate retrospectives, we need to do a better job rating/prioritizing the findings based on value to the team’s goal and setting expectations if any findings are not actionable by the team.

      Thanks!

  2. […] (You may recognize the name from an earlier blog about retrospectives in September 2010 here) […]


Leave a reply to Brilliant coaching insight « Musings Collection Cancel reply

Categories