Search

Tuesday, June 17, 2008

Retrospective Meetings

When we talk about Agile, we use the phrase “Inspect and Adapt”. "Inspect and Adapt” is a powerful aspect of agile. We inspect the progress of the game and adapt our plans to the reality of what is emerging. This is the purpose of the Sprint Review and Planning meetings. However it also applies to how we are making the game as well. This is the purpose of the Sprint Retrospective meeting.

The Sprint Retrospective is possibly the most important and neglected practice in Scrum. The goal of the meeting is to promote continuous improvement in how the team creates value in the game. This is accomplished in the Retrospective by asking key questions about the practices that benefited the team or worked against it during the last Sprint and to identify new practices that should be started during the next Sprint.

The Retrospective is where much of the long term change of the Scrum practices occur. The changes don’t necessarily have to be large ones. A one percent improvement in the effectiveness of the team every Sprint will compound into huge improvements over the long term.

The Retrospective meeting occurs following the Sprint Review. It run by the Scrum Master and is time-boxed. The amount of time spent in the meeting is determined by the team. The meeting is for the benefit of the team but anyone can attend.

This is done by answering three questions in the meeting:

What worked well last Sprint that we should continue doing?
The practices that worked well during the previous Sprint should be identified and continued in the coming Sprint.

What didn’t work well last Sprint that we should stop doing?
The team or customers should identify practices that worked against the team during the last Sprint and focus on stopping those things during the next Sprint.

What should we start doing?
The team identifies practices that should be implemented during the coming Sprint that will help them work better together.

People outside the team can offer suggestions as well. Some in the Scrum community suggest that the meeting is only for the team, but I believe that if a team interacts with people outside the team during the Sprint, then including these people in the Retrospective is valuable.

The Scrum Master will record all the answers given for each question. Unlike the Daily Scrum, there is a lot of debate and discussion that occurs during the Retrospective. The Scrum Master should mediate these discussions to keep the meeting within it’s time-box, but otherwise allow the discussions to occur.

Action items the follow from the answers don’t necessarily have to be assigned during the Retrospective. Below are some examples of answers to the question “what should we start doing” and some potential actions that could result:

“Start having QA approve all tasks marked “done” if possible”
This doesn’t require an action item as it would be a practice for the entire team to adopt.

“Make sure Joe tests his animations before committing them”
Clearly Joe has to follow up on his animation testing, but since this has to happen daily, there doesn’t need to be an action item.

“Have the build server send an email when the build is broken”
There might be an action item for the Scrum Master to pass along this request to the team that maintains the build server. If the team has a programmer who can implement this change, then the action might be to add this request to the team’s backlog.

Following the Retrospective, the Scrum Master will post the answers given during the meeting in the team area. During the following Sprint the Scrum Master will check off all the items that have been accomplished on the list. During the following Sprint’s Retrospective, any items left unchecked from the last Retrospective and discussed. These items can be either carried forward to the next Sprint or removed from the list based on what the team decides.

4 comments:

Anonymous said...

I agree with everything written here. The big problem wiht my team is getting them to talk, lots of times you ask 'what could we do to improve?' and I get...silence.

One resource I highly reccommend is Derby and Larsen's book, "Agile Retrospectives" (http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=sr_1_3?ie=UTF8&s=books&qid=1221455002&sr=8-3). I use exercises from that book all the time in retrospectives. My copy gets borrowed all the time.

r

Beverly Garland said...

R,
I find it helpful to get the "how to improve" discussion flowing by breaking it down in to chewable bites. First we identify the problem to solve (something that didn't go well). Then we talk about the contributing factors. I.e., what lead to this particular problem occuring? Once we understand the nature and context of the problem better, the team usually has a variety of solutions to offer, including how they might adapt their own practices to mitigate the contributing factors that lead to the problem.

YvesHanoulle said...

I agree with R, you need more ways of having retrospectives to keep retrospectives interesting for team members.
A retrospective is so much more then these 3 questions.
I prefer that the facilitator of the retrospective is a rotating role in the team. One reason is to have the scrum master participating, another is to boost the self-organizing aspect of the team.
The retrospective is the agile implementation if the double loop learning that organisations need to become a learning organisation.

yes to have outsiders as part of a team retrospectives. And they can only be there by invitation. Part of building a team, the team need a safe place to discus internal issue's.

Hady said...

Anonymous, something you can try with such a team is to get everyone to write their comments on a post-it note at the start of the meeting. After giving them sufficient time to do this exercise, put up each of their post-it note under the 3 different categories and get each person to talk about their idea.

You will find that this technique will be appreciated by people who fear being shutdown and will prevent discussions from going out of context.