Mark Needham

I've worked on two different teams this year which had quite different approaches to retrospectives.

In the first team we had a retrospective at the beginning of every iteration i.e. once every two weeks and in the second team we tried out the idea of having a rolling retrospective i.e. we put up potential retrospective items on the wall and when there were enough of those we discussed them in the standup.

The problem we had with the first approach was that we often had the same types of discussions in each retrospective and the same types of issues were raised each week so that it seemed almost pointless to even have it in the first place.

Several people ended up disliking the idea of even doing a retrospective in the first place because of this.

We came up with the idea of having a vote at the beginning of the iteration to decide whether or not we should have one with the idea being that if it didn't seem necessary then we could skip it for one week but would definitely then have the next one.

I think this worked reasonably well although it's slightly different to the approach taken by Rolf Knutsen which he discussed at XP2010 in his session on 'Feedback and Retrospectives in Agile Projects'.

Rolf suggested that we should have a retrospective at a given time interval and just cut it short if we don't have anything else to discuss.

I think I prefer Rolf's suggestion as it's too easy to come to the conclusion that we don't need a retrospective especially if we think that they're a waste of time.

I thought the rolling retrospective approach that we took on the second project would work much better as we could just address any problems as soon as they came up but it hasn't worked quite that way from my experience.

Several issues which would normally be addressed in a retrospective seemed to go by unchecked and without being resolved.

Having a retrospective is a very useful way to put people in a reflective mindset where they look for things that aren't being done well or that could be done differently whereas during the day we might not do that.

I hadn't appreciated this benefit of a retrospective session and had felt that problems were often being saved up for a retrospective even if they could have been addressed earlier.

Fabio previously wrote about the idea of the future retrospective box to ensure that we don't forget anything that happened early on in an iteration when we come to a retrospective but that still doesn't address the problem of only addressing problems in the retrospective!

It seems like a combination of having a pre scheduled retrospective with problem solving on a day to day basis is what we need so I'd be interested to know how others have addressed this.

Gojko Adzic posted a summary of a talk James Surowiecki gave at Agile 2008 and it got me thinking how we use the Wisdom of Crowds in Agile projects.

One of the most interesting things I learnt from the book is that when you bring together a diverse group of people, their output will probably be better than any one expert. Gojko points out this example that was used at Agile 2008:

The organisers of Agile 2008 conducted a similar experiment, asking conference attendees to estimate the number of lines of code in Visual Studio. The average value of all guesses was 47 million and the actual number is 43.3 million of code. The interesting thing as well is that only two people guessed better than the group average.

There are a couple of areas of agile where I have seen how The Wisdom of Crowds can become groupthink if we're not careful:

Agile Estimation Sessions

Agile estimation sessions are where the estimates for how long pieces of work will take are calculated.

The way these are typically conducted is the Business Analyst will explain the story to the team of Developers who will then all independently come up with their estimate of how long they think it will take to implement the story. They then 'throw down' their estimate in a rock-paper-scissors style approach.

The idea is then to take the most popular score suggested. If there is a difference in estimates then a discussion will ensue. It is often the case that the understanding of what is required to complete a story is different or different assumptions have been made as to the difficulty.

The value of having a group of people having input into a decision is most obvious when they are coming from different points of view i.e. they have diverse points of view.

Therefore the input of a new team member in these estimation sessions should in fact be vital for coming up with a better estimate. Often I see new members of teams choosing not to take part in these sessions which I think is a shame as their input could be very valuable as they will provide an angle on things that others may not have considered.

Speaking generally, a lot of developers think in a very similar way to each other so you actually end up with them giving similar estimates most of the time.

Retrospectives

Retrospectives are where the team gets together to discuss the project, how things are going, and areas where improvements can be made.

The first part of these sessions involves team members putting up on a white board things that have gone well, not gone well, and things that are confusing them to describe one particular retrospective technique.

As long as the safety of the group is fairly high then we can have a reasonable level of confidence that all issues are going to be brought up at some stage.

It is possible even with a perceived good safety level that team members can feel intimidated by others and they don't want to cause conflict by bringing up issues which will do so.

The voting system used to decide which topics should be discussed after the initial issues have been identified favours a team consensus. There might be an issue which should be discussed for the benefit of the team but if the majority decide it's not an issue then it may be left out.

The problem of having a lot of people who think in the same way on a team is again raised.

So what can we do instead?

In both agile estimation sessions and retrospectives the most value is gained from these sessions when the opinion of the group is better than any one individual. As I've suggested, however, there may be times when this is not the case.

Gojko suggests an interesting way to overcome this:

An immediate thing that comes to mind is to build teams out of people with different opinions. Have people on the team that think differently, use different tools and approach the problems from a different angle. This will help the team spot blind spots easier and avoid the echo effect, increasing the team collective intelligence.

While this is a good idea I think it is very difficult to implement in reality. It does suggest a very different model around team creation than is currently considered good practice.

When we form teams the emphasis is often on creating teams with the greatest skill around working with a particular language for example. Gojko's suggestion would involve creating a mixed team of Developers with different language specialisations for example. It would be obvious to see how someone coming from a Ruby background could bring a whole different perspective onto a Java project for example.

Assuming that we can't actually design our teams in this way we can still stay aware of groupthink and how we can avoid it.

In retrospectives we should do whatever is necessary to ensure there is an environment where everyone in the group can express their opinions. One easy way this can be done is to have an outsider facilitate the retrospective – this removes the possibility of an influential team member guiding a retrospective to fit their agenda.

In terms of estimation sessions we should always look to get assumptions out on the table for story cards and never dismiss the estimates of any one person. Using ideas such as pair programming to spread knowledge of a system more quickly is also useful for quickly helping provide team members with more context when making their estimates. There is much more on other techniques of agile estimation on Jay Field's article here.

I'm sure there are other ideas around these areas for making better use of The Wisdom of Crowds so it would be interesting to hear what you think.