Why the retrospective is not a lessons learned meeting
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.