Feedback is very important in tuning software development, but it's also needed in tuning the software development process. It comes in two major forms, introspection and retrospectives. Both involve looking back at what you've done, what went right, what could be improved, but introspection is solo and retrospectives involve the team.

In the "old days," a retrospective was called a project "post mortem," done after the project was finished and the team was about to disperse. A bit late to use the lessons learned in it, don't you think?

From experience and the literature I've read, post mortems are frequently skipped, especially on failed projects. And failed projects may have the most to teach us.

• Wisdom comes from Experience. Experience comes from making mistakes.

• RestrospectiveTechniques

• Singing the Songs of Project Experience: Patterns and Retrospectives by Linda Rising and Esther Derby from [http://www.estherderby.com/articles/rising-derby.pdf Cutter IT Journal] (PDF)

• Restrospective Agility by Tim Mackinnon in [http://www.ratio.co.uk/ov8pdf.pdf Objective View] (PDF)

• http://www.retrospectives.com/ Norm Kerth's website.

• Esther Derby's [http://www.estherderby.com/weblog/archive/2006_03_01_archive.html#114320660266333594 Seven Reasons to Have a Retrospective] and [http://www.estherderby.com/weblog/archive/2006_02_01_archive.html#114031552004362330 6 Reasons *not* to have a Retrospective] and [http://www.estherderby.com/weblog/archive/2004_05_01_archive.html#108548723203236478 What a Retrospective Ain't]

• Rachel Davies' [http://www.twelve71.org/blogs/rachel/archives/000752.html Heartbeat Retrospectives]

• Marco Abis' [http://brainscrum.wordpress.com/2006/05/22/retrospectives-in-and-on-action/ Retrospectives IN and ON action]