For years, I’ve seen people argue online about who should and should not be invited to a retrospective. In typical consultant fashion, my answer is “It depends.” Here I want to describe the dependencies so that it’s not such a mystery.
First, let’s define the basics so we have a foundation for the conversation. My definition of a retrospective is
- Looking at the past, together
- To gain insights
- And make choices for the future.
“Looking at the past, together” is what the word “retrospective” literally means. The word dates to the 17th century, and is formed from the Latin retro meaning “back,” and specere “look at.”
Let’s see how this affects the question of who should attend.
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. Read More
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. Read More
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. Read More
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). Read More
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? Read More
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. Read More
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. Read More