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.
- Zum Tag der deutschen Einheit mal ein Post in Deutsch: "Angst, Mut, Verantwortung, Disziplin" – http://t.co/hnaMZpZI #scrum #
- RT @mariofusco "Programming is the art of telling another human what one wants the computer to do" – Donald Knuth #
- If you consider yourself an engineer, you should know that the phrase "Adding to the equation" doesn't make sense at all. #
- RT @herbsutter What features would you like to see added soonest in your favorite C++ compiler? http://t.co/ZFZtYGDZ – Go vote! #
- .@herbsutter does not confuse IDE & compiler issues when talking about refactoring. Refactoring tools will use compiler to get job done. #
Joseph Pelrine hat auf der Agile Bodensee einen schÃ¶nen Satz gesagt (ich paraphrasiere aus dem GedÃ¤chtnis):
“Ãœber Scrum zu reden oder Scrum zu lehren / coachen ist viel leichter als Scrum tatsÃ¤chlich tagtÃ¤glich zu implementieren”.
Das Arbeiten im Scrum-Umfeld verlangt dem Entwickler einiges ab. Es bringt Ã„ngste zutage, erfordert Mut, Verantwortung und Disziplin:
- Angst nicht “ganz fertig” zu werden
- Angst sich vor den anderen Teammitgliedern zu blamieren
- Angst verantwortlich gemacht zu werden
- Angst daÃŸ eigene Defizite sichtbar werden
- Angst daÃŸ der Task mehr beeinhaltet als man absehen konnte
- Angst die notwendige Technik nicht zu beherrschen
- Angst nicht rechtzeitig nach Hause zu kommen
- Mut auch komplexe und unbekannte Aufgabenstellungen anzugehen
- Mut andere rechtzeitig um Hilfe zu bitten
- Mut eigene Defizite einzugestehen
- Mut Verantwortung zu Ã¼bernehmen
- Mut auch mal spÃ¤ter nach Hause zu kommen
- Mut Aufgaben auch nachtrÃ¤glich zu vereinfachen
- Mut nicht dem Sprintziel dienliche Aufgaben beiseite zu schieben
- Verantwortung, sich fehlende FÃ¤higkeiten anzueignen
- Verantwortung fÃ¼r die Gruppe zu Ã¼bernehmen
- Verantwortung fÃ¼r eigene Fehler zu Ã¼bernehmen
- Verantwortung fÃ¼r das Produkt zu Ã¼bernehmen
- Verantwortung pÃ¼nktlich zu erscheinen
- Verantwortung Informationen klar, prÃ¤zise und zeitgerecht zu vermitteln
- Verantwortung sich Ã¼ber anstehende Aufgaben zu informieren
- Disziplin den Test zuerst zu schreiben
- Disziplin auch wenn es zeitlich eng wird sauberen Code zu schreiben
- Disziplin immer wieder Ã¼ber das eigene Fortkommen transparent zu informieren
- Disziplin auch die unangenehmen oder unpopulÃ¤ren TÃ¤tigkeiten zu erledigen
- Disziplin komplexe Aufgabenstellungen in Ã¼berschaubare Arbeitspakete zu zerteilen
- Disziplin immer wieder rechtzeitig Hilfe einzuholen
- Disziplin bei jeder TÃ¤tigkeit immer wieder das Sprintziel im Auge zu haben