Retrospectives

Last week was the end of the first iteration on one of my projects. We had a review with the customer and then the project team held our retrospective. We really focused on 2 things; what did we do well that we want to continue doing and where can we improve for iteration 2.

I first learned about the concept of retrospectives after reading Norman Kerth's book Project Retrospectives: A Handbook for Team Reviews. You can also find more on his site, retrospectives.com.

To often I've been in organizations that pay tribute to the idea of "lessons learned" by holding a meeting after the project, writing some ideas down, and then forgetting about them when the next project starts. I've helped large, global organizations set up lessons learned databases so they can collect these lessons learned from project managers around the globe. None of this is any good without a key ingredient; changing people's behavior. Without that it's just a lesson documented.

I think agile principles really show the value of retrospectives. The retrospective isn't held after the project, it's held often, throughout the project so behavior can be changed immediately. After our meeting last week, we assigned a couple action items and we changed some of our patterns this week. Nothing major, just kaizen at its finest. In 3 weeks, at the end of the next iteration, we'll do it again.