Live and Learn with Retrospectives

Software development is not a solitary pursuit it requires collaboration with other developers and other departments. Most organisations establish a software lifecycle that lays down how these interactions are supposed to happen. The reality in many teams is that their process does not fit their needs or is simply not followed consistently. It's easy to grumble when this happens and it can be frustrating if you have ideas for improvements but are not sure how to get them off the ground. This article offers a tool that may help your team get to grips with process improvement based on the day-to-day experience of the team. Retrospectives are a tool that a team can use for positive change to shift from following a process to driving their process.

Retrospectives are meetings that get the whole team involved in the review of past events and brainstorming ideas for working more effectively going forward. Actions for applying lessons learned are developed for the team by the team. This article aims to explain what you need to do to facilitate a retrospective for your team.

Background

The term 'Retrospective' was coined by Norman Kerth author of Project Retrospectives: a handbook for team reviews [ Kerth ]. His book describes how to facilitate three-day off-site meetings at the end of a project to mine lessons learned. Such retrospectives are a type of post-implementation review - sometimes called post-mortems ! It seems a pity to wait until the end of a project to start uncovering lessons learned. In 2001, Extreme Programming teams adapted retrospectives to fit within an iterative development cycle [ Collins/Miller01 ]. Retrospectives also got added to another agile process, Scrum [ Schwaber04 ] and nowadays it's the norm for teams applying agile development to hold many short "heartbeat" retrospectives during the life of the project so that they can gather and apply lessons learned about their development process during the project rather than waiting until the end.

Learning from experience

Experience without reflection on that experience is just data. Taking a step back to reflect on our experience is how we learn and make changes in our daily lives. Take a simple example, if I hit heavy delays driving to work then it sets me thinking about alternative routes and even other means of getting to work. After some experimentation, I settle into a new routine.

No one wants to be doomed to repeating the same actions when they are not really working (some definition of madness here). Although a retrospective starts with looking back over events, the reason for doing this is to change the way we will act in the future - retrospectives are about creating change not navel-gazing. Sometimes we need to rethink our approach rather than trying to speed up our existing process.

Retrospectives also improve team communication. There's an old adage "a problem shared is a problem halved". Retelling our experiences to friends and colleagues is something we all do as part of everyday life. In a team effort, none of us know the full story of events. The whole story can only be understood by collating individual experiences. By exploring how the same events were perceived from different perspectives, the team can come to understand each other better and adjust to the needs of the people in their team.

Defusing the time-bomb

Let's move onto how to run an effective retrospective. Where a team has been under pressure or faced serious difficulties tempers may be running high and relationships on the team may have gone sour. Expecting magic to happen just by virtue of bringing the team together in a room to discuss recent events is unrealistic. Like any productive meeting, a retrospective needs a clear agenda and a facilitator to keep the meeting running smoothly. Without these in place, conversations are likely to be full of criticism and attributing blame. Simply getting people into a room to vent their frustrations is unlikely to resolve any problems and may even exacerbate them. Retrospectives use a specific structure designed to defuse disagreements and to shift the focus to learning from the experience. The basic technique is to slow the conversation down - to explore different perspectives before jumping to conclusions.

The prime directive

By reviewing past events without judging what happened, it becomes easier to move into asking what could we do better next time? The key is to adopt a systems thinking perspective. To help maintain the assumption that problems arise from forces created within the system rather than destructive individuals Norm Kerth declared a Prime Directive for retrospectives that he proposed is a fundamental ground-rule for all retrospectives.

This purpose of this prime directive is often misunderstood. Clearly, there are times when people messed up - maybe they don't know any better or maybe they really are lazy or bloody-minded. However, in a retrospective the focus is solely on process improvements and we use this Prime Directive to help us suspend belief. Poor performance by individuals is best dealt with managers or HR department and should be firmly set outside the scope of retrospectives.

Getting started with ground rules

To run an effective retrospective someone needs to facilitate the meeting. It's the facilitator's job to create an atmosphere in which team members feel comfortable talking.

Setting ground-rules and a goal for the retrospective helps it to run smoothly. There are some obvious ground-rules that would apply to most productive meetings - for example, setting mobile phones to silent mode. So what special ground-rules would we need to add for a retrospective? It's important for everyone to be heard so an important ground-rule is 'No interruptions' - if in the heat of the moment this rule is flouted then you can try use a 'talking stick' so only one person is talking at a time - the person holding the talking stick token (the token does not have to be a stick - Norm uses a mug and teams I have worked with have used a fluffy toy which is easier to throw across a room than a mug).

Once the ground-rules for the meeting are established then they should be written up on flipchart paper and posted on the wall where everyone can see them. If people start to forget the ground-rules then it is the facilitator's job to remind everyone. For example, if someone answers a phone call in the meeting room then gently usher them out so that their conversation does not disrupt the retrospective.

Safety check

Another important ground rule is that participation in exercises during a retrospective is optional. Some people can feel uncomfortable or exposed in group discussions and it's important not to exacerbate this if you want them to contribute at all. When a team do their first few retrospectives, it's a useful to run a 'Safety Check' to get a sense of who feels comfortable talking. To do this run an anonymous ballot, ask each person to indicate how likely they are to talk in the retrospective by writing a number on slips of paper using a scale 1 to 5 (where 1 indicates 'No way' and 5 'No problem') - the facilitator collects these slips of paper in, tallies the votes and posts them on a flipchart in the room. The purpose of doing this is for the participants to recognise that there are different confidence levels in the room and for the facilitator to assess what format to use for discussions. Where confidence of individuals is low, it can be effective to ask people to work in small groups and to include more exercises where people can post written comments anonymously.

Action replay

Sportsmen use the action replay to analyse their actions and look for performance improvements. The equivalent in retrospectives is the Timeline.

Start by creating a space for the team to post events in sequence that happened during the period they are reflecting over; moving from left to right - from past to present. Each team member adds to the timeline using coloured sticky notes (or index cards). The facilitator establishes a key for the coloured cards. For example, pink - negative event, yellow - neutral event and green - positive event. The use of colour helps to show patterns in the series of events. This part of the meeting usually goes quickly as team members work in parallel to build a shared picture.

The exercise of creating a timeline serves several purposes - helping the team to remember what happened, providing an opportunity for everyone on the team to post items for discussion and trying to base conversations on actual events rather than general hunches. The timeline of event is a transient artefact that helps to remind the team what happened but it is not normally kept as an output of the retrospective.

Identifying lessons learned

Once a shared view of events has been built, the team can start delving for lessons-learned. The team is invited to walk the timeline from beginning to end with the purpose of identifying 'What worked well that we want to remember?' and 'What to do differently next time?'

The facilitator reads each note on the timeline and invites comments from the team. The team work to identify lessons learned both good and bad. It's important to remind the team at this stage that the idea is to identify areas to focus on rather than specific solutions as that comes in Action Planning.

As a facilitator, try to scribe a summary of the conversation on a flipchart (or other visible space) but try to check with the team that what you have written accurately represents the point being made. Writing down points as they are originally expressed helps show that a person's concerns have been listened to.

In my experience, developers are prone to talking at an abstract level - making general claims that are unsubstantiated. As a facilitator, it's important to dig deeper and check assumptions and inferences by asking for specific examples that support the claims being made.

Action planning

Typically, more issues are identified than can be acted on immediately. The team will need to prioritise issues raised before starting action planning. The team needs to be realistic rather than wishful thinking mode. For an end of iteration retrospective, between three and five actions would be sensible.

Before setting any new actions the team should review if there are outstanding actions from their previous retrospective. If so then it's worth exploring why and whether the action needs to be recast. Sometimes people are too ambitious in framing an action and need to decrease the scope to something they can realistically achieve. For each action, try to separate out the long-term goal from the next step (which may be a baby-step). The team may even decide to test the water by setting up a process improvement as an experiment where the team take on a new way of working and then review its effectiveness at the next retrospective. Also it's important to differentiate between short-term fixes and attempting to address the root cause. Teams may need both types of action - a book, which provides a nice model for differentiating between types of action, is Edward DeBono's Six Action Shoes [ DeBono93 ].

Each action needs an owner responsible for delivery plus it can be a good idea to identify a separate person to act as a buddy and work with that person to make sure the action gets completed before next retrospective. Some actions may be outside the direct sphere of influence of the team and require support from management - the team may need to sell the problem! Your first action in this case, is to gather evidence that will help the team convince their boss action is required.

Wrapping-up

Before closing the retrospective, the facilitator needs to be clear what will happen to the outputs of the meeting. The team can display the actions as wallpaper in the team's work area. Or the team may choose to use a digital camera to record notes from flipcharts/whiteboards so the photos can be upload a shared file space or transcribed onto a team wiki. Before making outputs visible to the wider organisation the facilitator should need to check with the team that they are comfortable with this.

Perfecting retrospectives

To run a retrospective it helps to hone your facilitation skills - a retrospective needs preparation and follow through. The facilitator should work through the timings in advance and vary the exercises every now and again. A good source of new exercises is the book Agile Retrospectives [ Derby/Larsen06 ]. A rough guide to timings is a team need 30 minutes retrospective time per week under review so using this formula allow 2 hours for a monthly retrospective and a whole day for a retrospective of a several months work.

In addition, to planning the timings and format, the facilitator also needs to review: Who should come? Where to hold the meeting? When to hold the meeting? When a team first starts with retrospectives they will find that they come up with plenty of actions that are internal to the team. Once the team has its own house in order then they usually turn to interactions with other teams and it's worth expanding the invitation list to include people who can bring a wider perspective on these. As a team lead or manager it's hard to maintain a neutral perspective on events. If you work alongside other teams that use retrospectives then it may be possible to take turns to facilitate them for each other. As standard practice at the end of my retrospectives, I gather a 'return on time invested' rating from participants and this might be used a tool for assessing whether a new facilitator is doing a good job if you are trying to build a team of facilitators in an organisation.

Finding a suitable meeting space can make a big difference. It may help to pick a meeting room away from your normal work area so that it's harder for people to get dragged back to work partway through the retrospective. Where possible try to avoid boardroom layout - sitting around a large table immediately places a big barrier between team members - and instead look for somewhere that you can set up a semi-circle of chairs. You also need to check the room has at least a couple of metres of clear wall space or whiteboards. I have learned that when an offsite location is booked for a retrospective it's important to check that there will be space to stick paper up on the wall. I have sometimes been booked to facilitate retrospectives in boardrooms with flock wallpaper, bookcases and antique paintings so we used the doors and up-ended tables to create temporary walls.

As for timing, when working on an iterative planning cycle, you need to hold the retrospective before planning the next efforts. However, running retrospective and planning as back-to-back meetings will be exhausting for everyone so try to separate them out either side of lunch or even on separate days.

Final words

I am sometimes asked, by people wanting to understand more about retrospectives, 'Can you tell me a story that demonstrates a powerful outcome that resulted from a retrospective?'. I have come to realize that this question is similar to 'Can you tell me about a disease that was cured by taking regular exercise?'.

I have worked with teams where running regular heartbeat retrospectives made a big difference in the long term but because the changes were gradual and slow they don't make great headlines. For example, one team I worked with had an issue of how to handle operational requests that came in during their planned product development iterations. It took us a few months before we established a scheme that worked for everyone but without retrospectives it might have taken a lot longer.

The power of regular retrospectives and regular exercise is that they prevent big problems from happening so there should be no war stories or miraculous transformations! n

References

[ Kerth ] Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth. Dorset House. ISBN: 0-932633-44-7

[ Collins/Miller01 ] 'Adaptation: XP Style' XP2001 conference paper by Chris Collins & Roy Miller, RoleModel Software

[ Schwaber04 ] Agile Project Management with Scrum by Ken Schwaber. Microsoft Press, 2004. ISBN: 978-0735619937

[ DeBono93 ] Six Action Shoes by Edward DeBono HarperCollins 1993. ISBN: 978-0006379546

[ Derby/Larsen06 ] Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. Pragmatic Programmers 2006. ISBN: 0-9776166-4-9