Common Mistakes Teams Make in Retrospectives

Posted by Keith McMillan

January 10, 2012 | Leave a Comment

Something has been bothering me about the way I see many teams handle retrospectives. To be fair, it’s really several things. These common mistakes do more than make a retrospective less effective, they destroy any ability to achieve the purposes of a retrospective.When I first start to talk to people about the purpose of retrospectives, I usually explain it something like this: “It’s a good idea to look at ways to improve, and probably a better idea to do that during a project when you can still improve this project, rather than the next one.”

Baked in to this are some unspoken assumptions, such as the team can identify ways to improve, that they are willing to try those things, and that they evaluate whether they actually did improve as a result.  I’ve seen teams make some common mistakes when having a retrospective which completely defeat the purpose of the exercise, so in the hopes that you can avoid them, I recount them here, in no particular order.

Somebody Else’s Problem

One common mistake I see teams make is to identify lots of ways that other people, organizations, or sometimes the whole company should change, rather than ways in which the team itself can change.  This is a tricky area, because sometimes you can get others to change to make things better for you. Frequently you can’t, and so you get a better return by focusing on ways to be most effective in the face of these challenges, rather than trying to make them go away.

Focusing on Unpredictable Challenges

When looking at their performance over the previous sprint or iteration, some teams will identify challenges they could not predict at the start of the sprint, and that are unlikely to reoccur.  The poster child for this is team member illness. “If Bob had not been out for a week,” they will say, “we could have met our goals.”  That’s great, but you can’t schedule Bob’s influenza, so it’s probably best to focus on things you can affect rather than ones you can’t predict.

Not Agreeing on What to Change

This one is a favorite: teams will identify that something they are doing could be improved, but not discuss how they are going to change. “Inspect and Adapt” doesn’t really work too well if you don’t adapt.

Some teams have even said to me “We’re doing pretty well, I don’t think we need to change anything. Yeah, we’ve got this down!” While it may be true that you have a reasonable process, you will never have an exceptional one if you don’t continue to try to improve it.

Not Following Through

This one has been talked about ad infinitum, so I won’t say too much about it, but once you have identified something you could do to improve, you have to actually try it.  The number of times I’ve asked a team “how did we change how we worked this sprint, and did it make things better?” and received the sound of crickets in response…

Not Evaluating Whether You Improved

Ivar Jacobson spoke at an event I attended at a client’s site a number of years ago. I was actually working for his firm at the time.  He said that the IT industry in his view was very “trendy,” as in we liked to try out the latest process/tool/approach.  We seldom look back to determine if what we’re doing now is better, or just different. It’s prudent, when inspecting and adapting your process, to inspect it again and determine if what you thought would help actually works.

A final word on retrospectives that I hope will help you avoid all these problems. When you’re having a moment of reflection on your process, you should look for the following things:

  1. Is it something that is likely to recur?
  2. Is it something you can influence, either by expecting what will happen, or structuring your effort to avoid it?
  3. Is it something that makes a meaningful difference in how efficient your team is?

If you can find something that meets these criteria, you should focus on that as something to work with.  Then, you’ll be able to make a difference, rather than just make a change.




RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.