Looking Backward to Move Forward

A key element in Scrum is what happens at the end of a Sprint, namely the Retrospective. Now, I like many of you have sat through end-of-project "post-mortem's" many times in my career. Often, they are a sort of feel good review of the project over its life, comments are made about the good and maybe the bad, some notes are taken, everyone leaves and promptly forgets about what was said.

Not so in Scrum.

In fact, Scrum doesn't just promote an end-of-sprint Retrospective, it requires them. Remember that at the beginning of this series I said that Scrum's mantra is "inspect-and-adjust". Well, you can't adjust if you don't inspect. And if you don't adjust, you won't know what to change in a coming Sprint to make it work better. To that end, Scrum has some very specific rules about what to do in a Retrospective.

First, the Retrospective is held as a time-boxed meeting of no more than 4 hours. This occurs on the last day of the Sprint typically after an end-of-sprint review of completed items with the Product Owner. The whole team gathers minus the Product Owner (and any Chickens). This meeting is required so the Team needs to be encouraged to consider this a time when they can put their heads together and see what they can do to affect a future Sprint.

Second, there are 3 questions that are posed on a whiteboard, flipchart, etc for the group. They are:

What went really well (i.e. what do we want to continue)?
What didn't work very well (i.e. what do we can to stop)?
What do we want to change?

Similiar to the 3 question format of a Daily Scrum, the Retrospective has a similiar framework addressing the past and the future. What I do in these meetings is to write the questions on the board as columns. Then as people begin commenting on them, I start writing down their observations as the Scrum Master. You can start by "going around the room" in an orderly fashion or starting with the most vocal person first. In my experience, there are usually 1 or 2 people who are eager to get thoughts off their chest and this can initate a lively discussion. So I usually start by going to those people first. However, it's very important that each person get a chance to talk and no one is overlooked. It's perfectly fine if a team member doesn't have anything extra to add, but they do need to be encouraged to shout out anything that they can think of.

It's important as the Scrum Master to manage this meeting well and keep things moving along without rushing people. This can be a fine line. You don't want a meeting to degrade into off-topic discussions, or items which don't fit into the 3 question profile. Just as in a Daily Scrum, the meeting has a purpose and for it to be successful, it has to stay focused.

You may find also that one or more of the columns has few or possibly no entries. Although unusual, it's important that the Team with help from the Scrum Master find the items that go into the lists. As a Scrum Master, I will often mention some items I've observed myself particularly if the Team is struggling to get started, but in general the danger of a Scrum Master coming up with the list is that it turns into a typical meeting where one person does all of the talking and everyone else nods off.

The best Retrospectives are the lively ones where people feed off each other in the discussion and the Scrum Master acts as a coach keeping things moving along, writing down key points, and so on. You may find that you don't need the full 4 hours. In my experience, we've never needed that long to discuss a 30 day sprint. Once everyone is finished, the Scrum Master goes back over the list and asks if there are any final changes or observations. If not, the list is transcribed, etc into a more permanent format and provided to the Team. In our case, we use Microsoft Team Foundation Server and use that system to track retrospective documents for each Sprint. But you could send these out as email, paste them on the wall, etc. Whatever works, as long as everyone gets a copy.

Finally, the Team should be encouraged to review the list during the next Sprint. The items that shouldn't be continued should be dropped if possible, and suggested changes should be accomodated. However, if the lists are long, it's very unlikely that a Team will be able to make all the adjustments in a single Sprint. So it's important for people to make the number of changes that they think they can without undue pressure to make a major number of changes all at once. The key here is gradual improvement over time.

I've gone on about Scrum and its practices for several postings now. I think it's time to bring this to a close for now, but I'll come back to Scrum and Agile as time goes on. Hopefully, you've gotten an appreciation for how Scrum works, how flexible it is, and how significantly it can affect how your team creates software (or anything else for that matter).

If you are using Scrum, or decide to try using it, send me a note and let me know how you're progressing.

Posted by Mark M. Baker at 04:44 PM  Permalink