I was talking recently with a friend about separate retrospectives for sub-groups. They were worried about thing devolving into separate silos, with a retrospective for programmers, a retrospective for testers, a retrospective for analysts, …. I would be worried if that happened, too, but I can see value in separate retrospectives. How can we know when they’re appropriate and when they’re not? (Continued)
Tonight, we attended a lecture by Rich Wilson about the 2008-2009 Vendee Globe, a race around the globe by solo sailors in 60 foot overgrown sailing dinghies. While many sailboat racing talks get rather monotonous, this one was fascinating. Instead of talking just about boats and gear, Rich spoke mostly of the experience and the people involved.
He offered some advice that I think fits well with software projects:
In a race of four months, going 22 knots for a day doesn’t mean much. It’s just an opportunity to break things. It’s more important to raise the average speed from 10 knots to 11 knots.
This says something about sustainable pace, but it also says something about our tendency to measure ourselves by our peak performance according to some measure. Let’s face it–we’re only at those peaks for brief moments.
In the normal world of human endeavors, rather than artificial contests, the measure of “best” is never a measure of a single attribute. I would say that the measurement scales for our performance are so numerous and varied that we are never “best” by all of them at once. Perhaps we are not at our peak even for brief moments.
Yet we can always strive. And even when we don’t achieve that which we desire, or that which we think we’re capable of achieving, we may still be doing our “best” under the circumstances. In fact, how could we not?
Bob Payne and I talk about retrospectives. This is a topic dear to my heart. Most scrum teams could do a lot better on these.
I just noticed that Bob Payne has posted an interview with Esther Derby on the Agile Toolkit Podcast. This interview took place at the end of the Agile 2008 Conference and covered a number of topics. The topic that I found most interesting and timely was that of retrospectives, and ways to make them actually accomplish something instead of just talking about the same things repeatedly. (Continued)
Retrospectives seem to mean many different things to different people. At least, that’s the way it happens in practice. People approach retrospectives in different ways, with different motivations, and that naturally leads to very different experiences and outcomes.
Venkatesh Krishnamurthy wrote about Retrospective Smells in which he quoted some cautions I’d posted on the Lean Software Development yahoogroup. This was in response to Allan Kelly’s mention of his blog post, The Trouble With Retrospectives, which was, in turn, mentioned in response to Robin Dymond’s announcement of his new Retrospectives Wiki. (Continued)
Dale Emery wrote a wonderful post about the Prime Directive on the ExtremeProgramming yahoogroup. This blog entry is mostly to prevent me from losing track of Dale’s comments, as is easy to do on a busy mailing list. I want to be able to go back and re-read his words. (Continued)
Last week I was corresponding with Esther Derby on the use of the Prime Directive in retrospectives, and how some people express difficulty in accepting it. She followed up that discussion with an excellent post on the topic, where she lists many reasons why someone may be doing their best under the circumstances, though not doing their peak work. When I saw that, I shelved the article I’d been writing on the topic. It’s remained on my mind, however, and I still have a bit to say about it.
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.
– Norm Kerth, Project Retrospectives: A Handbook for Team Reviews