Mark Needham

Following on from my blog post about some observations about the actions that we create in retrospectives I’ve also noticed some general ways that retrospectives might not end up being as useful as we’d hope.

Having a manager facilitating

While having the manager of the team facilitating the retrospective isn’t a problem in itself I think it’s useful to remember that in this context they aren’t in that role anymore.

I’ve noticed that there can be a tendency for people to direct any comments they make during the retrospective towards the manager, thereby excluding others from the conversation.

Having the facilitator call out their role at the beginning of the retrospective and encourage participants to address any comments to the group can help to counter this situation.

Facilitator participating

Another closely related pattern is that of the facilitator participating in the retrospective and it’s easy to see why it happens since if the facilitator is part of the team then they probably have some opinions that they want to share as well.

Unfortunately what I’ve noticed happen is that they end up giving their opinion on the points made by others and if they have an opposing opinion to someone then it can easily discourage that person from participating any more.

One way to get around this problem is to have an external facilitator and the other is for the facilitator to realise that their role in this meeting is to facilitate and keep their opinion to themself!

Collecting/Analysing information

Another common problem I’ve seen is the attempt to try and combine the collecting and analysing of data for the iteration.

I find that the problem with doing this is that we can easily end up belittling people’s observations if they get analysed and dismissed without being written up on the whiteboard.

Collecting all the data as one activity and then working through it after everyone’s had a chance to make their contribution is a much more effective way to do it.

Focusing on things out of the team’s control

While it’s useful to identify things that are going wrong which are out of our control it can quickly get very boring for everyone if those things get brought up repeatedly.

Quite often we don’t have the ability to address some things straight away but once we’ve gained a bit more trust we might get the chance to in future.

We’ve sometimes had retrospectives where you were only allowed to bring up things which could be addressed by the people in the room and this worked reasonably well.

It is still useful to remember which things we want to try and chance but can’t at the moment so that we can try again in a couple of months time.

My colleague Ashwin Raghav wrote a blog post earlier in the week in which he noted some patterns that he’s noticed in retrospectives in his time working in ThoughtWorks.

In it he talks quite generally about things he’s noticed but in my experience one of the areas in which teams typically struggle is when it comes to action items.

Too many action items

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:

Often you’ll find tens and tens of things to improve, accept the fact that you probably can only change three of them, and focus on that.

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.

Action items that noone is passionate about

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.

Group ownership of actions

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.

Action items that are difficult to measure

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.