Each place that I've worked, I have always seen a "Lessons Learned" step as a part of the standard process for projects. It's always baked into the methodology with an expectation that it'll get done. In reality, I've them to be a step that doesn't produce much more than negative feelings across teams and a bunch of finger-pointing. Maybe that's only my experience but as a project manager, I'm always looking for ways to focus on the positive and to continue momentum. This is where retrospectives come into play. Years ago, I was introduced to Agile development methodology. I got formal training, then earned my certifications about four years ago. As a part of my Scrum project management training, I learned about the retrospective held at the end of a project or process, where successes and improvements were discussed. I felt empowered. Finally, a positive way to look at a completed project. The retrospective spins "lessons learned" on its head and enables the team to have the input they need to make things better. If you've never conducted one, here are some basics about retrospectives that might pique your interest. In any development environment (waterfall or agile), I use this method of learning, instead of lessons learned.
1. Look Ahead, Not Behind
Traditional "lessons learned" meetings look backward. They usually end up with some version of finger-pointing or lack of participation due to fear of "where the words will go." They also miss the point of figuring out how to truly improve. Retrospectives focus only forward. The basics include "things that worked" and "areas for improvement." The outcome should be a list of agreements that the team can work on for the next iteration or work cycle. Tip: In order to get the most out of the session, only the immediate team should participate. This is slightly different from a lessons learned format. A retrospective is really about the team learning how to improve. It's not for airing dirty laundry and making anyone uncomfortable. If you have the right people in the room, the discussion should flow much better once you get going. The outcomes are also for the team, so be careful how the data you report is viewed. Remember, too, that the output is how this specific team can improve, and it may not transfer to other teams.
2. Get Insights Into How the Team Works
Retrospectives let you start understanding how teams work well together. It's important that we constantly review how things are moving and make little corrections along the way. If you wait until something major rears its head, it's much harder to improve. By making small changes along the way, it's easier to have a better impact. If minor issues aren't dealt with, they may blow up. Be proactive about all items mentioned and ensure that the team agrees with how to move forward. Tip: The team needs to be confident that the discussions won't come back to bite them. Be sure to set your sessions up to reflect your true intentions. I personally believe that the sessions should be closed — and so should the comments. If that's your intention, keep it that way.
3. Actions Are Key
It's critical to summarize the key items coming out of the retrospective. Gain buy-in by discussing them and conducting rating exercises to define which to focus on during the next iteration of the project. If you only talk about things to do and don't actually follow through with actions, the team won't improve and may not trust the process the next time around. Tip: When defining the key items to focus on for the next effort, be conscious of what the team can handle, as well as the items with the most votes or the highest priority. Point them out at appropriate times — either how things are getting better, or not. Doing this will help keep the proposed items of change at the forefront of everyone's mind.
