Archive for the ‘retrospectives’ tag
At the start of most of the retrospectives I’ve been part of we’ve followed the safety check ritual whereby each person participating has to write a number from 1-5 on a sticky describing how they’ll be participating in the retrospective.
1 means you’ll probably keep quiet and not say much, 5 means you’re perfectly comfortable saying anything and the other numbers fall in between those two extremes.
In my experiences it’s a bit of a fruitless exercise because its viewed that a higher number is ‘better’ and therefore the minimum people will tend to write down is ‘3’ because they don’t want to stand out or cause a problem.
I’ve been in retrospectives where the majority of people were a ‘4’ but then when it came to a contentious topic only 1 or 2 people contributed so I’ve become a bit sceptical of this safety check approach!
- Explorers are eager to discover new ideas and insights. They want to learn everything they can about the iteration/release/project.
- Shoppers will look over all the available information, and will be happy to go home with one useful new idea.
- Vacationers aren’t interested in the work of the retrospective, but are happy to be away from the daily grind. They may pay attention some of the time, but are mostly glad to be out of the office.
- Prisoners feel that they’ve been forced to attend and would rather be doing something else.
Phil pointed out that in this case each of the possible categories describes how people will contribute to the retrospective whereas the traditional safety check is more about their degree of comfort with the environment.
I don’t have enough data points to declare that this is better than the 1-5 approach but from my experiences it seems that there’s less pressure on people to fit in one of the categories since none is ‘better’ than the other, just different.
In a recent retrospective where we used this it led to a conversation where people explained why they had chosen a particular category, which I thought was quite fascinating and something I haven’t seen happen with the numbers approach.
My instinct is that if someone actually felt like a ‘Prisoner’ then they might not actually categorise themselves as that but I haven’t seen this approach used enough to say that for certain!
I facilitated the latest retrospective my team had last week and decided to try The 4 L’s technique which I’d come across while browsing the ‘retrospectives’ tag on del.icio.us.
We had 4 posters around the room representing each of the L’s:
- Longed for
I’m not really a fan of the majority of a retrospective being dominated by a full group discussion as many people aren’t comfortable giving their opinions to that many people and therefore end up not participating at all.
I’ve seen much more participation if the facilitator tries to encourage less vocal people to give their opinions and if the first part of the retrospective is done in smaller groups.
We therefore started in groups of three where people discussed the previous iteration and came up with ideas which they stuck under each section. That lasted for around 15 minutes.
After that we split into groups of about 5 – one for each of the L’s – and each group spent 6/7 minutes grouping together the stickies and looking for any trends.
One member of each group then presented a summary of their section to the rest of the group and suggested what they thought the most important thing to discuss was.
Having gone around all of the groups we now had 30 minutes to discuss the 4 topics we’d identified. In fact two of them were the same so we only had 3!
My observation of this style of retrospective is that it seemed to achieve the goal of getting more people to participate. At least 2 or 3 people who have never spoken in one of our retrospectives before were giving their opinions to the whole group.
I was curious to see whether we’d cover all the topics that people wanted to discuss as I cut the whole group voting system which I’ve seen used in most retrospectives I’ve attended.
After we’d finished discussing the 3 main topics a couple of other points were raised which had both been on the ‘longed for’ wall.
We ended up just quickly agreeing to give these things a try for an iteration instead of having a prolonged discussion about the advantages/disadvantages of the idea.
Facilitating wise I think I could have been clearer with my instructions as people were a bit confused at times about what exactly they were supposed to be doing.
I think it’s vital to get everyone in the group involved early on or they just zone out and their insight is lost.
I’d be interested in hearing other types of retrospectives people have run which allow you to do that.
One of the approaches that I like the best in retrospectives is when the facilitator splits the team into smaller groups during the brainstorming part of the retrospective.
I decided to try this out in a retrospective we ran after one week of ThoughtWorks University, using The Retrospective Starfish to provide a framework in which people could frame their thoughts.
Usually what I’ve seen happen in these mini groups is that everyone will write down their own ideas on stickies and then discuss them as a group but still put up all the stickies even if the group didn’t agree with everything.
Frankie observed that in this retrospective that hadn’t really happened and the mini groups had been reaching a consensus on their ideas before one or two people went and put them up on the wall.
I think this partly came down to my failure to explain the intent of the exercise clearly i.e. it is a brainstorming exercise rather than an analytical one.
An interesting side effect was that when people came and looked at the wall to see what the other groups had come up with they noticed quite a few things that they agreed with but hadn’t come up with in their group.
I think next time I’ll try and explain the exercise a bit more clearly to help keep people in the mindset of coming up with ideas.
It’s difficult to say if any important points were missed by people analysing so early but there was certainly less duplication of ideas than normal!
Despite being part of numerous retrospectives over the past few years I don’t remember actually facilitating one until my current team’s last week.
I’ve gradually come to appreciate the skill involved in facilitating this type of meeting having originally been of the opinion that there wasn’t much to it.
I recently read Agile Retrospectives which has loads of different ideas for activities beyond just creating ‘went well’ and ‘could improve’ columns and then filling those in as a group.
In the best retrospective I’ve attended recently the facilitator had us work together in small groups while coming up with ideas to fill in on the retrospective starfish.
I really like the idea of working in small groups because I think it encourages more participation in the discussion of problems on the team.
My general observation is that a sizeable percentage of people are more comfortable taking part in discussions in smaller groups than with the whole team (~ 25 people).
We split into groups of 4 or 5 and then populated a time line of the project since the last iteration before going across the board and discussing the most prominent topics.
These were some of the main areas that I had thoughts about during and after facilitating this retro:
Perhaps somewhat ironically given the amount I’ve been hassling my team mates to keep meetings short this one over ran by about 25 – 30 minutes, taking around 90 minutes instead of 60.
I had a rough idea of how quickly we needed to move across the board in order to finish on time but it got thrown completely off track by one point which resulted in a much longer discussion than I had expected.
I tried to move across the rest of the items a bit more quickly to make up for that but it didn’t really work.
I’d be interested to hear what a more experienced facilitator would have done in this situation as I’m sure it’s very common.
I’ve written previously about the dangers of giving your opinion when facilitating a retrospective so I tried to make sure that I kept out of any discussions that happened and allowed others to talk.
On a couple of occasions I was asked to give my opinion on certain things so I had to step out of my facilitating role temporarily, join the discussion and then step back in.
I think this worked reasonably well but I can see how it would be difficult to keep quiet if you had really strong opinions on a topic being discussed!
Summarising the discussion
I see part of the role of the facilitator being to try and summarise what is being discussed so that it can be written up afterwards and distributed to the team.
I didn’t realise how difficult this is, especially if the discussion drifts slightly away from its original direction.
I found it quite tricky to follow what was going on at times but luckily one of my colleagues was able to help me out when I didn’t quite get it right.
Overall it was an interesting experience and I hope I’ll get another chance to try this role again soon although for now we’re trying to rotate it around the team to give everyone an opportunity to facilitate.
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.
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!
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.
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.
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.
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 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.