The Retrospective Prime Directive:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
What a great starting point for generating a safe environment during a sprint retrospective. A safe environment is important for a successful retrospective. However, starting with the prime directive will not generate a successful retrospective. Let me explain.
If I start thinking about the last sprint with the prime directive in mind, it is close to impossible for me to see how I could have done better. Because I did the best job I could – that’s what the prime directive said. If I’ve done the best job I could, what could be improved? Because my knowledge & skills are what they are, it sure is the situation at hand and the resources available which could be improved: The story wasn’t workable, the automated acceptance tests were sorely lacking, the build server failed all the time, the code was using this incomprehensible template stuff, the compiler was too slow, I had too many meetings, there are always conflicts when I try to commit my code, the APIs encountered are too complex, the product owner wasn’t available for questions 24/7, the unit tests ran for ages and slowed me down, the Scrum Master didn’t moderate each and every meeting & discussion – etc. and so forth.
If you’re using the prime directive as a starting point, you’re framing your mind the wrong way.
What happened to individual responsibility, to laziness, to procrastination, to lacking technical skills, to a lack of practice, to inefficient use of my time, to a lack of knowledge, to stalling, to stepping up to the plate and saying “I have to do a better job and I need to do something about it”?
Why don’t we start with the Retrospective Prime Questions (you bet I made up this phrase 2min ago)?
- What could I have done to make this sprint more successfully?
- How could I have behaved differently?
- What should I have done to help my teammate accomplish his task?
- What could I have contributed to improve the process?
- What do I have to learn in order prevent this from happening again?
- What can I do to improve our environment?
Maybe we would come up with action items like this:
- Mary will fix this §$%& build server. Joe will help her out, he’s a Jenkins wizard. They’ll get right to it on Tuesday morning.
- Mark will help improving our unit tests performance – he has some great ideas on how to make that happen.
- Erwin needs to use Skype to contact the product owner with questions instead of stalling. Our Scrum Master will help him by reminding us in the Daily Scrum that the product owner is on the road.
- Joe needs to understand this %&$§
templatestuff. He will sit down over the weekend for a few hours, read up on it and do some experiments. Jack said he will work with him over a beer next Wednesday night and help Joe getting histemplatesstraight. Mary said she’ll join Joe & Jack, too as she’s unsure if she really got variadic templates. Our Scrum Master will make sure that there’s plenty of free beer available to make this a pleasant experience. - We will check the top stories on the product backlog regularly and see if they’re workable. I will start doing that tomorrow morning before the daily meeting. 10 minutes & a good coffee should be enough to do that.
- Paul will update his code from the repository multiple times a day to avoid deadly conflicts. We’ll set up a kitchen timer for him as reminder.
- Marvin needs to ask the Scrum Master to help out if his discussions spiral out of control. Erwin, who’s sitting next to Marvin will help with notifying the Scrum Master in time.
- John knows a little bit about this Cucumber thing, he’ll sit down with the product owner next week to show him how to use it. This will bring us closer to automated acceptance tests.
- Hans will ask our Scrum Master about recommendations on how to improve his verbal communication skills.
Disclaimer:
I’m neither a professional Scrum Master nor a Product Owner nor a Scrum expert. I’m just an ordinary software developer trying to deliver valuable, clean software. Most of the time, I’m failing. And it’s not because my environment is to blame or because there are impediments beyond my control. It is because I have to do a better job. And I want you to help me do that.
[Update]
Another take on this topic can be found at What’s wrong with the Retrospective Prime Directive?.
[/Update]
[Update]
My Scrum Master just sent me this link: NAIKAN. Looks like a worthwhile (Warning: German Language) exercise to encourage self-reflection.
[/Update]
[Update]
Very nice German language post on this very topic: Der Flügelschlag eines Schmetterlings.
[/Update]
[Update]
Great take on re-phrasing the Retrospective Prime Directive: Another Alternative To The Retrospective Prime Directive. Here’s a nice German translation by Nicole Rauch.
[/Update]
[Update]
Another take on this very topic by Thomas Mayer – The Prime Defective.
[/Update]
I think you misunderstand the prime directive here. It is a statement about the intentions of all involved persons, not about how they did perform in the sprint.
If you really think on the other hand that one of the participants of the retrospective did act with sabotage on their mind… well a retrospective will not be the adequate setting to correct that, anyway.
And I am afraid that “Because my knowledge & skills are what they are” is completely missing the point. The retrospective is a chance for you to LEARN. This means your knowledge changes!
Having done the best job you could _at the time_ does NOT mean that you wouldn’t do a better job now.
Thanks for your feedback, Holger.
What I’m trying to say is that the prime directive frames the discussion. The prime directive makes it hard to reflect on the developers own contributions (or lack thereof), because it kind of “sets the mood” for the following discussions. I’m not debating the merit of the prime directive to state the intentions of the individual team members, I’m debating that the prime directive makes it very easy to the individual to (sub-consciously) start with from the promise “I did my best and I have a certain knowledge and a set of skills”. This makes it very hard to critically reflect on the individuals performance.
I’m trying to suggest that there are better ways to frame the discussion in a retrospective than the prime directive.
I think you are saying: “The prime directive makes the team members feel too comfortable to really search for the painful truths.”
I think its purpose is exactly the opposite: It enables the team to criticize individual performance without falling into the trap of mutual blaming.
Maybe I am a coward, but I’d rather have a team member too comfortable to find the “real root cause of all problems”(TM) than to have my team explode in discord because we thought there must be someone to blame for our failure.
Good point, Holger.
I agree that the purpose of the prime directive is to enable looking for the root cause of the failure without getting into the blaming game. I don’t debate that. That’s a great purpose. I don’t want to get into the blaming game. I believe in respectful, but honest communication. I’m just wondering if the prime directive actually encourages everybody to look for the root cause – which, quite often, is individual performance. And judging from my experience, it doesn’t do that job. That’s why I’m wondering if there are other “directives” or “starting points” or “framing question” for a retrospective which avoid the blaming game and encourage self reflection.
RT @DavidHolzer1976: Flügelschlag eines Schmetterlings http://t.co/HK1NpHNJ – Ähnliche Idee wie http://t.co/ZBUa0hHL #scrum #retrospective
And a completely different take on the PrimeDirective RT @berndschiffer: PrimingPrimeDirective http://t.co/YmAGMtP6 Why you should read the Retrospective Prime Directive out loud before _every_ retrospective.
Good find, thanks Holger.