A key part of the agile development lifecycle, retrospectives are something we should do regularly.
The general format retrospectives I have been in take:
- Quick look at the actions from the last retrospective – was everything completed that was meant to be?
- Three columns are drawn on the whiteboard – ‘Good’, ‘Bad’, and ‘Confusing’.
- Everyone is given post it notes and writes down short points about how they felt the iteration went. The advantage of using post-its here is that it makes you think about how you write your point as you don’t have much space, and this can be a good starting point in the later discussion.
- When everyone has finished writing their points, each person in turn puts one card on the board under the correct heading, and this is discussed. At this point similar cards can be grouped together, with others who have written the same (or very similar) point, adding their card too. This continues until everyone has run out of cards.
- The cards in the ‘Bad’ column are discussed to find actions to avoid the problem happening again.
- The cards in the ‘Confusing’ column are discussed, with a view to clearing up the confusion if possible, or making a plan of how this can be done if not.
- Finally whoever led the retrospective then writes up the actions that arose, giving each action an owner (which can be the whole team), which is then emailed around shortly after the restrospective.
These work well because I have worked in small teams, so this format encourages everyone to take part, without meaning that the whole process will take hours.
James Carr’s blog post ‘Retrospective Patterns has some interesting ideas about alternative formats of retrospectives. Most interesting is his idea of beginning each retrospective with everyone writing a single word on a post it note about how they felt the iteration went. Then after looking at all of these together, the format for the rest of the retrospective can be determined. For example, if all the words were positive, you can then work out why that was by using the 5 Whys technique. The team discusses the strengths that contributed to it being a good iteration (with examples), and these are written on the whiteboard. Then each person is given a number of dots, and they use these to vote for how important they feel the strengths are. The ones which are viewed as the most important are then taken to try and improve upon. This is good if the iteration went perfectly, because it means that strengths can be capitalised on for the next iteration. However it is important not to overlook negative points, and these often give rise to a more concrete plan of action for the future.
The above method would work well in larger teams as it requires participation from everyone at the beginning with the one word post it, then smaller teams can be formed and the ‘whys’ discussed. So everyone has an input, but not at the expense of the retrospective taking too long. Another way as detailed here, is to split the large team into two or three to discuss what to improve in the next iteration. They have two minutes to come up with two points, then two minutes to present back to the other groups. After this five minutes are spent prioritising the list of points. The time frames here are useful to ensure discussions don’t get too bogged down with detail, although the final five minutes may have to be flexible in very large groups. This also has the advantage of producing a list of actions for the next iteration that is already prioritised.