Approaches to Retrospectives

I had the distinct pleasure of working briefly with Tim Wingfield a few months ago. Bright guy. We were talking recently about different retrospective approaches. One of his teams was in a rut with how their retrospectives were going. They tend to only be the griping and airing of grievances style and they weren't getting actionable items. Everyone was caught up in the complaints.

The great thing about agile is that you can be agile in order keep from getting into a rut. Each new client has a different situation which gives me opportunity to focus on a one aspect of agile more heavily than at another client. I get to try different nuances each time.

The neat thing about retrospectives is how applicable they are and how easy they are to apply outside of IT. Today I was sharing some of my approaches with a cycling friend whose realty group, Dillard & Company, uses a genuine team approach. I say genuine because they are a team in the real sense of the word. They aren't just a group or loose federation that incorrectly calls themselves a team.

Anyway, I had these approaches in my head and Tim had commented that my retrospective artifact was a little different than what he had seen described in writing so I thought I'd put them down in a blog post.

I tend to use a flip chart for the retrospective when I have a dedicated space in which I can leave a big visible chart. Unfortunately, my clients often lack sufficient space. So I find that I most often end up using a white board and then transcribing the retrospective notes into some tool like VersionOne or into a wiki. I like using the whiteboard during the retrospective, but I don't like hiding the results online.

When I use a flip chart, I find it convenient to draw quadrants. When I use a whiteboard, I just do columns.

Either way, in these quadrants or columns I often write:

• what went well
• what did not go well
• do more of
• do less of

Sometimes I use:

• good
• bad
• do differently

Less often I use SaMoLo:

• Same As
• More Of
• Less Of

I may use "opportunities" instead of "bad" or "did not go well". It depends on the tone of or presence of animosity in the team and whether certain terms are emotionally charged.

There are times when I really want to dig into things and fully understand what's going on. I facilitate the whole discussion. I often start out with "so, what happened this iteration?" Or, "what went well?" Or, "how did it go?" I try to record the essence of what people say. Be a good facilitator. Elicit input from the quiet ones. Try to cover each of the areas at least a little. I may dot-vote for the one or two issues to attack in the next iteration, if consensus isn’t obvious. This approach can take a while. I use this approach the first few times with a client or when we have largish iterations. If people get impatient, I don't use this approach.

Once I'm through that stage I like to switch to this other approach. I have everyone come up to the whiteboard all at once and write whatever they want in any of the columns. I request that they briefly tell someone in the room about what they just wrote. I listen in for themes or things I want to dig into during the discussion that I have once everyone is done writing. I often don't write anything of my own, but I may if I see something important missing. This gets us through the kudos and complaints more quickly so that I can get on to the "do differently" items and find some specific action item to take away. I have gotten a lot of positive feedback on this approach. Everyone feels more engaged. It gets them out of their chairs and their blood pumping.

Another approach is to ask people to write their thoughts on sticky notes. You can then read them or have them read them. You can have the team do an affinity grouping of them. I'm not sure how to keep that approach from dragging on too long, but I can see how it can help elicit input from the quiet ones.

One other thing I like to do before I run a retrospective is skim over what we recorded in prior retros. If I find an issue that was brought up over and over but that never made it into an action item, I’ll just start the retrospective with that and figure out how to solve it.

Other than in that instance, I never exclude the opportunity for people to complain about something. It's important to have a release valve, an opportunity to blow off some steam. But we don't have to dwell on it. Some things you are just not going to solve and other times just mentioning an issue can solve it.

I mix it up because it's important to do retrospectives in different ways. Regardless of how I run it, I always look for one specific, measurable, achievable, actionable action item as an outcome of the process and I make sure it has an owner.

Of course, Esther Derby's Agile Retrospectives book is a great resource for more ideas.