The very first Agile Coach I ever had taught me the practice of using Norm Kerth’s Prime Directive to start my retrospectives. Though I haven’t always used it, when I do I find that it sets the right tone for the Retrospective.
Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, give what was know at the time, his or her skills and abilities, the resources available, and the situation at hand.
The Scrum Retrospective is Important
I’ve written about the Retrospective process extensively Improving Your Retrospectives Part 1, Part 2, and Part 3. I believe the retrospctive is the most important event in the Scrum Framework. As Jeff Sutherland and Ken Schwaber say, the purpose of the retrospective is to make the team process more effective and enjoyable. It is important to do it well, so invest some time in improving your retrospective.
Improve the Retrospective by Creating Psychological Safety
The reason I like the prime directive, is that it sets a tone of non blame, which goes a long way to improve the retrospective. In fact, if your goal is to improve your retrospectives, it is probably the most urgent thing you can do. It helps establish psychological safety, something that studies have shown is a key ingredient for high-performing teams. I previously wrote about the Aristotle study at Google that demonstrated the importance of psychological safety.
Going into a review with an attitude of acceptance and non blaming is important. Learning doesn’t happen when people are busy blaming, defending, or covering up.
The DevOps Handbook describes the importance of creating safety in what they call the blameless post-mortem. The blameless post-mortem is a carefully facilitated review of every incident or production failure. Authors Gene Kim, Jez Humbold, and others link psychological safety to organizational learning.
When engineers make mistakes and feel safe when giving details about it, they are not only willing to be held accountable, they are also enthusiastic in helping the rest of the company avoid the same error in the future. This is what creates organizational learning.
They also describe what happens when we don’t provide that safety in our reviews:
On the other hand, if we punish that engineer, everyone is dis-incentivized to provide the necessary details to get an understanding of the mechanism, pathology, and operation of the failure which guarantees that the failure will occur again.
In other words, if we don’t make it safe to talk openly about problems, we will be doomed to repeat them over and over again.
So I like to use the Prime Directive and I feel it can really improve the retrospective. In fact, I used it for two retrospectives that I facilitated this week. I opened the retrospective by reading the Prime Directive aloud and asking everyone if they can agree to it.
How Do You Improve Your Retrospectives?
How about you? Do you do anything similar to reading the Prime Directive? What other tips can you share to improve the retrospective process?