TITLE: Agile Themes: Honesty and The Prime Directive AUTHOR: Eugene Wallingford DATE: July 26, 2007 1:21 PM DESC: ----- BODY: My last post looked at the relationship between honesty and blocking, motivated by a recent thread on the XP discussion list. In another thread, I encountered Dale Emery's message on The Prime Directive, and that got me to thinking about being honest with myself about my own behavior, and how to get better. If you read much in the agile world, you'll run across the phrase "Prime Directive" a lot. I'm not a Trekkie, though I have enjoyed the several movies and TV series, but the first thing I think of when I hear the phrase is James T. Kirk. That's not what the agile folks are talking about... even if that directive raises interesting questions for a software person introducing agile methods to an organization! If you google "prime directive agile", the first link is to Bob Martin's The Prime Directive of Agile Development, which is: Never be blocked. This is an ironic choice of words, given what I discussed in my previous post, but Martin is using an analogy from billiards, not football: An agile developer "makes sure that the shot he is taking sets up the next shot he expects to take.... A good agile developer never takes a step that stops his progress, or the progress of others." This is a useful notion, I think, but again not what most agilists mean when they speak of the Prime Directive. They are referring instead to Norm Kerth's use of the phrase in the realm of project retrospectives, in which teams learn from the results of a recently-completed project in order to become a better team for future projects. Here is the Prime Directive for retrospectives, according to Norm:
The prime directive says:This directive creates an environment in which people can examine past actions and results without fear of blame or reprisal. Instead the whole team can find ways to improve. When we look back at behavior and results in this context, we can be honest -- with our teammates and with ourselves. It's hard to improve oneself without facing the brutal facts that define our world and our person. Emery's article focuses on the power of the phrase "given what they knew at the time". He does not view it as a built-in excuse -- well, I didn't know any better, so... -- rather as a challenge to identify and adjust the givens that limit us.
At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass.
- 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.
I apply The Prime Directive to my personal work by saying, "I did the best I could, given..." then fill in the givens. Then I set to work removing or relaxing the limiting conditions so that I perform better in the future. Usually, the most important conditions are the conditions within me, the conditions that I created.... If I created those conditions (and I did), then they are the conditions I can most directly improve.Well said. Being honest with myself isn't easy, nor is following through on what I learn when I am. I take this as a personal challenge for the upcoming year. (By the way, I strongly recommend Norm Kerth's book on retrospectives, as well as his pattern language on the transition from software analysis to design, Caterpillar's Fate. Norm is an engaging speaker and doer who celebrates the human element in whatever he touches. I reported on a talk he gave at PLoP 2004 on myth and patterns back in the early days of this blog.) -----