The biggest weakness of a traditional “lessons learned” meeting is that they come too late to do any good on the current project. Furthermore, they aren’t particularly effective for the next team, as that team isn’t working on the exact same project nor do they necessarily have the same team members. Add these up, says Keith McMillan, and you have a recipe for ineffective adjustments.
What Can Be Changed?
McMillan explains how the simpler approach of an Agile Retrospective allows teams to think more openly about what can be changed:
When I coach teams through retrospectives, I frequently use the common “do more”, “do less” and “keep doing” categories for provoking thoughts about what we could do to be more efficient. There are some common things I try to get teams to think about. I encourage them to think about activities they are doing that add little value to their work, such as documenting changes to the design of software. Even if a team is performing some activity and must continue to do so, I encourage them to think about whether what they are doing is the most efficient thing both for them, and for whoever consumes the product of their activity. Continuing the thought of updating a formal design document, are the updates taking the form that’s easiest for the team to do, and most easily used by whoever is reviewing that design.
If there are still problems generating areas to work on, McMillan suggests creating “interesting” and “frustrating” categories for teams to speak to, which might change the frame of mind enough of retrospective participants to gain some valuable areas to work on.
Read the full article here: http://www.adeptechllc.com/2013/02/28/agile-concept-of-the-week-retrospective/