Blame has no place in retrospectives

While writing a post about retrospectives and deltas, in response to an article by Deborah Hartmann on InfoQ (Frequent Retrospectives Accelerate Learning and Improvement), I noticed a disturbing comment mentioning the "traditional blame party".

Deborah's post referred to and quoted from an article by Rachael Davis entitled "How To: Live and Learn with Retrospectives". The quote from Rachael's article included the following sentence.

Without these in place, conversations are likely to be full of criticism and attributing blame

Rachael's comment, when put into context of her article, is about avoiding a situation resulting in blame, however, while the commentor's remark may have been facetious, it seems "blame" in retrospectives is a reality.

Attributing blame, be it in a retrospective or in the development process seems to me to contradict some important elements of eXtreme Programming.

The principle of Accepted Responsibility and the practice of Collective Ownership (which comes out of the Shared Code practice) both imply that the team accept and own the decisions collectively. Pointing the finger tends to do nothing but breed resentment and cause people to "switch off" to potential solutions to the problems.

Finally, attributing blame in a critical manner ends up breaking the core value of Respect.

I think it's an important role for a manager to encourage an environment where people feel "safe" to raise issues in a retrospective without feeling that blame will be attributed.