Refactoring Your Development Process with Retrospectives

Rachel Davies, Agile Experience Limited.

http://www.agilexp.com

Software development is not a solitary pursuit, it requires collaboration with other team members and departments. Most organisations establish a software lifecycle that lays down how these interactions are supposed to happen. The reality is that many teams find that development 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 that don�t get taken up. This article offers a tool that may help your team get to grips with process improvements. This tool is the Retrospective. This article aims to explain what you need to do to facilitate a Retrospective for your team.

Background

A Retrospective is meeting which gets 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.

The term "Retrospective" was coined by Norman Kerth author of "Project Retrospectives: a handbook for team reviews" [1]. 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 [2]. Retrospectives also got added to another agile method, Scrum [3] 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. Often on a project, no one person knows 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 use structured group activities to slow the conversation down � to properly explore different perspectives on events before drawing 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.

Prime Directive: Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

This purpose of this prime directive is often misunderstood. Clearly, there are times when people messed up � maybe they don�t know anybetter or maybe they really are lazy or bloody-minded. However, in a retrospective the focus is solely on making improvements and we use this Prime Directive to help keep us in constructive mode. Poor performance by individuals is best dealt with managers or HR department and the Prime Directive firmly sets such conversations 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 additional 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 � it could be an object from your office such as a mug - 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 all activities 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 will I share my point of view" and 5 "Completely comfortable to talk openly") � 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 subsequent discussions. Where confidence of individuals is low, it can be effective to ask people to work in small groups and to include more activities 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 (on the wall) 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 activity 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?", "What to do differently next time?" and "What still puzzles us?".

The facilitator reads each note on the timeline and invites comments from the team. The team works 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 up a summary of the conversation on a flipchart (or other visible space) and 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. Such as, "the architect is never around", "we always have problems with environments", and "there are too many meetings". As a facilitator, it�s important to dig deeper and check assumptions and inferences by asking for specific examples to 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, no more than three and five actions would be a sensible limit.

Before setting any new actions, the team should review whether 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). For example, a long term goal might be "implement continuous integration" and a short term goals might be "create a script to automate the build", "refactor tests to remove dependencies on live database so tests run in less than 10 minutes", "install Bamboo tool".

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 De Bono�s "Six Action Shoes"[4].

Each action needs an owner responsible for delivery plus it can be a good idea to identify a buddy to 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 � to get that support 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 needs to check with the team that they are comfortable with doing 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 activities used every now and again. For example, rather than using a timeline for data-gathering you might ask the team to focus on a specific aspect of their process (such as design reviews or testing) and use a different activity to explore this. A good source of new activities is the book "Agile Retrospectives" by Esther Derby & Diana Larsen. 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 it�s own house in order then they usually turn to interactions with other teams and it�s worth expanding the invitation list to include people from outside the immediate team who can bring a wider perspective.

As a team lead or manager, it can sometimes be hard to play the role of neutral facilitator when you have opinions and observations you would like to share as a participant. 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 (ROTI) rating from participants and if you are trying to build a team of facilitators in an organisation then gathering such participant feedback is likely to be useful to help new facilitators get a sense of how they are doing and can be used to gauge the effectiveness of any type of meeting.

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 setup 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 fancy boardrooms with flock wallpaper, bookcases and antique paintings and had to resort to using doors, windows and up-ended tables to create temporary wall space.

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 change 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! Embracing retrospectives helps a team fine-tune their process at a sustainable pace.

References

Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth. Dorset House. ISBN: 0-932633-44-7 "Adaptation: XP Style" XP2001 conference paper by Chris Collins & Roy Miller, RoleModel Software Agile Project Management with Scrum by Ken Schwaber. Microsoft Press, 2004. ISBN: 978-0735619937 Six Action Shoes by Edward De Bono HarperCollins 1993. ISBN: 978-0006379546 Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. Pragmatic Programmers 2006. ISBN: 0-9776166-4-9

More Scrum and Agile Resources

Agile Videos

Click here to view the complete list of archived articles

This article was originally published in the Fall 2007 issue of Methods & Tools