Why the retrospective is not a lessons learned meeting

by Lyssa Adkins on January 31, 2011

Often, when I introduce agile newcomers to the retrospective, they say, “Oh…this is the lessons learned meeting.  Right?”  Well, no.  It’s not.  Tongue-in-cheek, I often say, “It’s like lessons learned, but with a purpose.”  This gets eyebrows raised and people’s ears turned on.  Then they are ready to hear why this “meeting” is so different.  Here are some reasons why:

It’s not about posterity, it’s about tomorrow. In my prior life as a plan-driven project manager, I held lessons learned meetings, often at the end of the project.  The idea was that we would be able to cycle those lessons “in” to the next project.  It never happened.  Not that I didn’t try – I did!  Neat tables, documented according to the latest template, offered up long lists of what the project team did well, what they didn’t do so well and what they *could* do about it.  The words would swim before my eyes as I scanned row after row of insights (?!) that never seemed applicable to my current situation.  Because they weren’t.  They were insights for a different team, a different business problem, a different time. It turned out that these lessons were captured more for posterity than for applicability.  In contrast, the few agreements that come out of a retrospective are directly applicable to the current team, the current business problem and the current time – now!  That’s why it’s like lessons learned, but with a purpose.  The purpose is to cycle those insights, in the form of real agreements, right into the next sprint with the goal of yielding improvement the team can see.

It’s not about airing everything, it’s about getting the top insights.  In the retrospective, experienced agile coaches steer away from facilitating the team to create lists of *everything* they did well and *everything* they want to change.  A new coach may start with this “plus/delta” format.  I did.  It’s OK as a starting point, but don’t stay here.  Instead, do what experienced coaches do — design an interactive retrospective that allows the team members to see the last sprint through a different lens or from a different angle, but certainly, with new eyes. (Great book for this: Agile Retrospectives) Everyone’s story about the last sprint is 100% right (for them).  And, the stories conflict with one another.  So, its not so useful to try to get “agreement” on what happened.  Better to design a retrospective that wakes people up and makes them think differently about what they just experienced in the sprint so they can uncover the top 2 or 3 insights about how to be better next time.  We don’t need lists of everything.  We need a short list of the important things.

It’s not about talk, it’s about action. I can often be heard asking, “What will you do?” as the retrospective draws to an end.  Thanks to Eric Willeke, whose post about gaining commitment on what the team members WILL do made me realize that I also coach the team into action.  I don’t badger, bully or force but I do heckle a bit.  I might say, “OK, this has been a lovely retrospective but means nothing if you don’t change something.”  With that small nudge, they do.   They always commit to change something for the better.

It’s not about feeling good, it’s about following through. After the retrospective, the retrospective is not over, at least not for the agile coach.  It continues throughout the next sprint as team members struggle with their agreed-to actions (or maybe forget them entirely).  This is when the agile coach remains on alert for that perfect moment when pointing to the retrospective agreements pasted to the wall provides a gentle and firm reminder that we weren’t just fooling around about making these changes.  A well placed, “Are these still relevant?” might be all they need to jog their memories and get them consciously practicing and improving again.

No 50-page document here.  Nothing stored on a shared server for audit purposes.  Just real, useful, insightful and timely agreements about what we’re doing NOW to be even better than we were last time.  That’s the retrospective.

{ 4 trackbacks }

Tweets that mention Why the retrospective is not a lessons learned meeting -- Topsy.com
January 31, 2011 at 1:22 pm
QuickLinks for February 2011 | (Agile) Testing
February 28, 2011 at 6:12 pm
Pre-Mortem Exercise
March 2, 2011 at 2:56 am
Confluence: Project Management Continuity
October 30, 2013 at 2:24 pm

{ 3 comments… read them below or add one }

Angie Schottmuller (@aschottmuller) September 20, 2012 at 1:39 pm

Awesome post! Totally logical. The need for clear process and documentation can often over step it’s usefulness. Bringing us back to simplicity is refreshing. The point of be actionable is such a key to efficiency. Who wants to sit through a meeting that’s not actionable??? This post totally just reshaped how I’ll be doing a “lessons learned”/retrospective with my team. Thanks!

P.S. The SEO in me still wants to call it “lessons learned”, but I get your point on trying to frame it up as “retrospective” to add-in the actionable part. =)

Sami Lilja February 3, 2011 at 12:55 pm

Thanks for an excellent post and a view of how an agile coach can use retrospectives to improve teams’ work.

There is one point I’d like to disagree, with respect, of course :-)

I have seen too many action-oriented retrospectives. People (especially managers) are eager to see “improvement”, which of course starts with an action plan. This easily leads to an action-oriented session, with maybe 15% attention to learning and the rest of the session dedicated to action planning and finding measures & responsible person.

Retro-Spective, as the name suggests, is actually looking back and learning. I always advise people to learn first and move into action later. If actions are missing, that’s OK when learning happens. Having actions without learning is probably the worst outcome.

Having said this, I fully agree with your point about following through and commitment to change. These are equally important as learning, and coaches have an essential role in helping organizations get from “should have been done” to “was done”.

Thomas Juli February 2, 2011 at 2:24 am

I couldn’t agree more. Retrospectives as much as effective lessons learned workshops need to be purposeful, need to be results-oriented. For this purpose it is crucial to prioritize the output of such sessions. In other words, what are the top 3 lessons learned and action items we take home from the retrospective and want to focus on during the next sprint. This does not mean to neglect the other feedback which didn’t make it to the top 3. It is a call to focus on the most pressing issues first – rather than scattering your energies. It is futile to try to juggle all balls at the same time. It is doomed for failure and frustration. Instead, decide with your team the top 3 most valuable lessons learned and accompanying action items and follow through.

Leave a Comment

Previous post:

Next post: