Retrospective Principles

I’ve talked about the goals of a retrospective. Now I’d like to talk about four principles of effective retrospectives. I generally find that principles help me more to be effective while doing my work than do definitions. Principles help to connect the abstract to the actual practice.

One of the principles is that it’s important to understand the goals. If you don’t know where you’re going, any road will take you there. That road is, however, unlikely to be a retrospective. As a facilitator, I find the general goals helpful in planning a retrospective. I think that the specific goals are valuable to the participants, and generally discuss them as part of Setting the Stage at the beginning of the retrospective. As always, this is moderated by the understanding of the participants and the time available. (Continued)

Goals of a Retrospective

In my previous post, I talked about what a retrospective is not. Understandably, I got immediate questions about what a retrospective is. This post is a partial answer to that.

My current definition of a retrospective is “looking at the past to guide choices for the future.” That definition, however, is insufficient to offer guidance on making your retrospectives effective. It’s even insufficient to distinguish what I would call a retrospective to those who use the word for other similar or related activities. A retrospective is different from a “post-mortem,” a “lessons learned,” or many other forms of “process improvement,” but is often confused with these.

A retrospective should have a purpose. If it’s merely a formality, it’s unlikely to provide much benefit. Perform your retrospectives mindfully, thinking about your goals prior to the retrospective and choosing activities to meet those goals.

You may have many different specific goals for different retrospectives. Whatever the specific goals, the general goals of a good retrospective seem to fit three categories. (Continued)

The Wrong Impression about Retrospectives

People get the wrong impression about retrospectives. They read that it’s a meeting where you list what went well, what didn’t, and what you want to change. They describe it like this:

The Sprint Retrospective is an opportunity for team members to bring up anything about the Sprint they feel needs improvement.  For example, a team member might say he felt he had to complete work that should have been completed by another team member.  Or a team member might say she received emails constantly which prevented her from getting any work done….

Or like this:

The format is a discussion and brainstorming. The ScrumMaster facilitates the retrospectives and let the team choose what aspect they want to improve for the next Sprint. Because the team is very technical, most of the discussion revolves around improving engineering practices, i.e latest frameworks, continuous integration, BDD, etc. Improvements get accomplished. But the point is the team thinks that rather than allocating special time to do retrospectives, they said why can’t they just do that within the sprint? The team gets the idea from Kaizen that is implemented in Toyota where the team gather in an instance to find a way where they can improve rather than going to a specially allocated sprint retrospective. (Continued)

Safety Exercise

In my recent posting on Separate Retrospectives, I mentioned sometimes performing a Safety Exercise at the beginning of a retrospective where the situation was unknown or seemed a bit charged with emotion. I was asked about that exercise.

I use a simple poll of how safe people feel. I got this from Norm Kerth’s book, Project Retrospectives (page 110). (Continued)

Separate Retrospectives

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)

Project advice from a solo circumnavigator

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?

Podcast on Retrospectives

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.

Making your retrospectives more effective

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)

On Retrospectives

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 on the Prime Directive

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)