Saturday 27 July 2013

The best way to conduct a retrospective meeting

Retrospective meetings on SCRUM IT development projects are held at the end of the sprint (usually at 2, 3 or 4 week intervals). The purpose of this meeting is to collectively find out how the team can become better and more effective.

If you are not doing SCRUM development projects you can still use this meeting style. It is all about learning and continuous improvements so this should be relevant for any team (3-8 persons) that is working together over a long period of time, in any type of organization.

Over the years I have been on many development projects and tried different approaches to the retrospective meeting. The following format and structure seem to work very well.

Duration 

2 hours. Usually you will see others saying 1 hour is enough. I think 1 hour can be a bit too short (if you are more than 4 persons) because then you don't really get the time to discuss and "analyze" issues.

Roles

You will need one facilitator (In SCRUM this will be the Scrum master). The facilitator can simply be one of the team members.

Who should attend?

The core team including designers and testers. Scrum master/project lead and product owner.

Preparations

In your daily work keep a notebook at your desk. Immediately when you recognize a possible issue or idea suitable for the retrospective then write it down. Keep one page in your notebook dedicated to notes for the next retrospective. This way you avoid going to the retrospective meeting with a blank head. Even though the meeting is held every 2, 3 or 4 weeks it can be hard to remember things that happened during the sprint.  

The meeting

Timeline

The facilitator initiates the meeting and draws a timeline on a whiteboard. Indicate on the timeline the start date and end date of the sprint. Also put in the half sprint date on the middle of the timeline so it is easier to position post-it notes later.

Each participant then writes down events that happened during the sprint. This should be limited to events that affected the team in some way. Each participant will sit around a table and try to come up with notes without looking on the notes of the others. Write with big letters so it is easy to read when it is put up on the whiteboard.

Events should be relevant. Negative events that seem to be reoccurring should get extra attention. Other private stuff can often be left out. If for example you moved to a new apartment and had to take a day off and where distracted during the sprint, this will affect the team but there's no need to mention it here because there's probably nothing you or the team could do about it, and there's nothing the team can learn from it.

Take turns and put up a post-it note for each (positive and negative) event. No need to discuss each post-it note here. Just be objective and concise. The post-its will make the next step much easier.


What went well and what went not so well

Now start a new round where each participant tries to come up with notes for things that did not go as smooth as it could. On a separate wall or area of the whiteboard take turn and present your note.

The events in the previous step will help you remember things that did not go as well as it could. Each participant presents their note and how they experienced it. Do not make suggestions for solutions at this point and above all do not blame others.

Remember that others may have experienced it totally different. The important point to make here is that all team members get to discuss and share their perspective. Typically you'll discuss it as a problem and what this problem leads to. How severe is the problem? Maybe you are the only one seeing the problem. In that case maybe you need to change your perception of the issue.  

Another important point to make here is that talking about things that did not work out very well can be difficult. It can even become uncomfortable or stressful. Now it's important that you act as a team and help each other. Be honest. We all have strengths and weaknesses. Also, think in systems. When someone messes up, it is usually the system that allows or encourages him or her to do so. Find the underlying causes. Here the 5 whys technique can help to find the root cause of the problem. When a person does something he shouldn't then recognize that there is a weakness in the system. If someone made it happen, it might happen again. Change the system, not the person.

Now take another round of post-it writing. This time it will be more positive and uplifting. Write down what went well. Here you can take the opportunity to pat your team members on the shoulder. If they took initiative to improve something but did not succeed you can still make a note on the effort. You an also brag about what you yourself did that you think worked out particularly well. Usually there's not much to discuss here but it is still important. Most people thrive when they get positive recognition from their peers.


Looking back to the previous retrospective meeting

The facilitator now put up the post-it's from the last retrospective on what to start doing, stop doing, and continue doing. In the previous meeting you made some suggestions for change. Now you can evaluate the changes that have been made since last time. Did you see any improvements? Has anything been done at all about the things you identified in the previous round? Sometimes people agree to make changes, but when you meet up at the next retrospective, nothing has changed. In this case you may want to evaluate your incentive systems. Boring tasks are often postponed when the reward seem low, intangible or distant.


Suggest changes

The facilitator draws 3 columns and adds post-it's from the last meeting. Based on what changes were made this sprint you can now suggest adjustments by coming up with ideas for what to start doing or stop doing. Combine this with solutions for the newly identified problems (what did not go so well). Each participant makes another round with post-it's:
  • Stop doing
  • Continue doing
  • Start doing
This again is discussed in the group. If there is a consensus on a topic the post it will be transferred to the next retrospective. In many cases the stop, continue and start doing thing will be a bit vague. In that case you will need to make more concrete action points. Some of the items will be for the whole team or some of the team members to do. Other items may be for the organization to carry out. In the latter case it will be the responsibility of the scrummaster/project lead to see that it is actually carried out.

Prioritize action points and follow up on them. Put them in your product backlog, to-do list, task tracking system, podio, basecamp or whatever you are using. The items may even be new innovative ideas to register in your idea management system. I happen to work for a company that is developing idea management software. Visit our website inductsoftware.com for idea management software to improve your organization's innovation capacity.

Learn more about retrospective meetings at the Agile Retrospective Resource Wiki.