Today's invited talk is on project retrospectives, and a retrospective on the book "Project Retrospectives" by the author, Norman Kerth. The idea: after a project (any sort), it's a good idea to sit back and discuss what lessons were learned from it.

It's not enough to just gather and identify "what went wrong" and point fingers - the idea is to have the retrospective become a post project ritual that focuses on learning, not blame. For purposes of the retrospective, assume that everyone did the best job that they could at the time with the skills/tools/resources available to them at the time. Example: The campfire discussion of the buffalo hunt in "Dances With Wolves". The upshot: No one person has a complete picture of what happened - you need the perspectives of all the participants, so you can see the things you missed.

Important - you want an "atmosphere of safety" in order to get honest (and complete) feedback. The key things to learn in a retrospective:

• What worked well?
• What have we learned?
• What would we do differently next time?
• What still puzzles us?
• What needs furher work?

The way corporate culture changes is by changing the stories they tell about themselves. Constant learning implies a continual change in the way work gets done. Many organizations simply don't want to change. Some teams do want change:

• Agile teams
• Software Process Groups
• Teams at Wits end
• Consulting firms
• Highly Dynamic firms by design
• Disaster Response teams

Retrospectices can also be useful after milestones are reached, or after a merger, or after a manager/lead has been replaced. in other words, after an important event.

Good question: What do you do about people who lie, or spend their time working to undermine someone else? The idea is to focus on the events that happened, not on the people themselves. Seems to me that this might require a highly focused facilitator with many teams.