Mark Needham

Thoughts on Software Development

Retrospectives: General observations

with 3 comments

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.

Written by Mark Needham

November 6th, 2010 at 5:17 pm

Posted in Agile

Tagged with

  • Venkatesh

    @Mark. I hope you are having quite a nice time in Pune. I wish you A Happy Diwali. :)
    Such another nice posting. Thanks for that.

    Regarding facilitator: You are right, the retro facilitator has to be someone from outside the team. When I was in Blr-TW, I remember we always ensured that. Any kind of manager in our team was a participant, just like any of us in the retro. We also try to invite a facilitator who is from a non-managerial background. This avoided lots of uninvited influences and side-effects.

    Collecting Data: After TW, I was assigned a PHP team to whom I had to introduce Agile practices, during those retro’s, even though we collected the observations through post-it’s, I insisted on writing the observations on WB before we start analyzing them. And the whole team get a chance to analyze that and group them. It avoided the chance of loosing any observation.

    For focusing on things out of team’s control: The best thing as far as I had seen working is, to quickly identify and keep storing those kind of points separated out for discussing later. Once we are done with other points, we analyze these points to see if any of’em deserve to be part of top 3 action items we would derive. If yes, identify the person or team who could help us on this and publish our action items to them as well. We also used to find a owner within our team for these action items whose job is to facilitate the outside person with all the help required to resolve the problem.

  • Mark Needham

    @Venkatesh – I guess it’s nice to always have an outside facilitator but sometimes it’s difficult to make it happen! More so when you’re on a client site rather than in a ThoughtWorks office to be fair!

    That’s a cool idea re: things out of the team’s control, will have to give that a try.

  • Diana Larsen

    Hi Mark,

    I want to underscore your point about focusing on issues the team controls for taking action. A while back I blogged about a way to help the team sort their issues to clarity which belong to them and which to others.

    Thanks for this series of posts on retros.