I think this is probably the number one mistake that we make in retrospectives and it’s really easy to make.

We find so many things that we can improve in our team and we want to try and do all of them straight away.

This sounds a little similar to what Dan North has been talking about in his Agile Architecture talk at QCon in San Francisco:

Having any more than 2 or 3 action items probably means that the majority of them aren’t going to happen so we need to prioritise and make sure only the action items we really care about are recorded.

Even if we do manage to reduce the number of actions that we list it’s often the case that we’ll get to the next retrospective and nothing will have been done about many of them.

I think this stems partly from the fact that it’s really easy to suggest that something be added to the action items without considering whether or not there is someone in the team that is really passionate about making sure that it happens.

This often happens when we volunteer 'owners' for actions rather than someone being enthusiastic enough that they just want to go and fix it.

My current thinking is that if noone really wants to drive forward an action then we should just cross it off the list rather than fool ourselves into thinking it will get done.

We recently came up with an action that was applicable to all developers on the team - around recording technical debt while working on stories -and I didn’t see the value of assigning an 'owner' to that action.

A colleague pointed out that if we had group ownership for that action then it would mean that nothing would happen because collective responsibility typically means no responsibility.

He added that it would be useful to have one or two developers paying particular attention to that item until the approach was engrained in the team’s mentality and everyone just did it by default.

Another common mistake is to come up with action items which are very difficult to measure i.e. we can’t tell whether or not we succeeded in executing the action or not.

In Agile Retrospectives the authors suggest that we ensure our actions are S.M.A.R.T which I think is a reasonably good idea although I’m not a fan of management acronyms!

I prefer to just check that with each action we’ll be able to know by the next retrospective whether or not we’ve managed to do it and if what we did worked.