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 his
templatesstraight. 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.
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.
Another take on this topic can be found at What’s wrong with the Retrospective Prime Directive?.
My Scrum Master just sent me this link: NAIKAN. Looks like a worthwhile (Warning: German Language) exercise to encourage self-reflection.
Very nice German language post on this very topic: Der Flügelschlag eines Schmetterlings.
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.
Another take on this very topic by Thomas Mayer – The Prime Defective.