The Retrospective

Note: This post is one of a continuing series re Scrum Intro. The preceding post is here.

Basics

We usually think of the Retrospective as the last meeting of the Sprint. But what is the difference between the Sprint Review and the Retrospective? The Sprint Review is about the product. The Retrospective is about the process, or I prefer to put it this way: The Retrospective is about how we become better as a team, “continuous improvement.”

Who comes? The whole team — the Implementers, the SM and the PO. They can invite others, which does happen sometimes.

Also, if the Implementers are afraid of the PO and will not tell the truth if the PO is there, then that is an important impediment, especially for this kind of meeting. So, the SM may have to ask the PO to skip one or two meetings, until the SM can get them to tell each other the truth. But, real soon they all must become used to telling the truth with the PO there.

If they can’t tell the truth with the PO there, perhaps the wrong person is the PO, or perhaps the team needs to have more courage. What is the time-box? According to the Scrum Guide, the Retrospective is three hours for a four-week Sprint. This implies 1.5 hours for a two-week Sprint. I am OK if you use two hours every two weeks.

This meeting is often not done well, and often not done at all (typically because it was not done well it was more or less useless). Do this meeting well, and we are about to give some advice that will make it a more useful meeting.

Purpose

The purpose of the Retrospective is to become better, measurably better in some dimension, in some way. Typically we want to improve velocity (productivity). This is a good thing, but it presents problems. If you tell a team to improve productivity, they usually hear that as “work more hours.”

So, somewhere the manager and the team have to agree on this:

1. We are not working more hours. We are working 40 hours per week (or some reasonable number).
2. We will be having more fun. Fun is essential to innovation work, and we will measure this with the Happiness Metric (Cf Jeff Sutherland’s blog).
3. We will improve velocity a lot, 100 percent in the first six months.

Always you have to discuss these three things together. They won’t believe it at first.

The purpose could be something else than increased velocity, although whatever it is, it usually influences velocity eventually. Maybe higher quality, maybe faster learning, more better motivation, maybe higher Business Value, maybe more fun, etc., etc. OK, so that gives the context and purpose.

I like to divide the meeting into two time-boxes.

Part One

The first time-box is small. It consists of the following quick discussions we suggest. (There are alternate ways of doing it, and once they master the basics, we do recommend changing things some.)

What went well

Take a moment to celebrate the things that went well. Ask everyone to do more of the good things, and to do the good things more often.

What sucked

I like to be blunt and honest. There are always things that sucked. We were dumb, managers tried to kill us (it seemed), the servers deiced to crash, etc., etc.

Our own imperfections

It is important that we identify our own imperfections as a team, that we identify the supposed evil in other and that we complain about the world. All of these are true, and it is helpful up to a point to talk about them.

We are identifying the impediments as we did in the Daily Scrum, and, remarkably, we identify some of the same ones (no surprise) and some new ones. Anything that slows the team down in any way is an impediment. A lack of a ping-pong table could be an impediment, technical debt, an interfering manager, a missing team member, corporate culture, a lack of babysitters — anything.

Let me emphasize this. It is human nature to be reluctant to speak publicly about one’s own imperfections. Nonetheless, that is what we must do. These are always some of the more important impediments because everyone is imperfect, and we can see this daily (e.g., in the Daily Scrum) it becomes less hard to be honest.

Still, if you are the SM, good luck getting them to be completely honest, especially at first.  What they are used to is this: “The beatings will continue until the morale improves.” Usually the more specific version is the blame game. You have to change this.

I hope I am exaggerating the problems at your place with people being honest, and maybe I am, but often I am not exaggerating.

Impediment List

We already by now (before this meeting) have an Impediment List with the top 20 impediments, and if it is a Top 20 list, there are usually 20 things already on the list that we could work on to improve. Virtually always most of the “things that sucked this Sprint” will not break into the Top 20 list, but some will. One new thing might go straight to the top of the list.

So, one value is: They got some things off their chest, they got to moan a bit (as all humans must do) and they see that most of their impediments are not that important, and they can live with most of them and move on. This is useful. More about the Impediment List later.

The key thing for now is that it is prioritized, based on the benefit/cost of the impediment, or maybe it’s better to say the ratio of the benefit achieved by mitigating or fixing the impediment over the cost of fixing it. So, again, a few of the impediments identified in this meeting will break into the Top 20 list. This is useful, because we are going to take action on the top (1) impediment.

The ScrumMaster Report

Next, I recommend the ScrumMaster Report.  (This is not a paper report.  This is the ScrumMaster updating the team.) The ScrumMaster has 10 minutes to “justify his love” (as Madonna suggested) for the team. That is, 10 minutes to explain what he or she has done the past two weeks to help the team:

• the impediments has she worked on
• the impediments has she taken to a manager
• the impediment(s) has she gotten fixed
• how much has the velocity improved this Sprint (due significantly to the SM)

The team (and the SM) expect the velocity to usually improve every Sprint by a small amount. (Rome wasn’t built in a day.) The rest of the team starts to see how the SM is useful and they are surprised. The SM is surprised that they did not think (before) that he or she was valuable — but now do.

Prioritize the Top 4 Impediments

Next, the SM leads the team to quickly prioritize the Top 4 impediments (from the Top 20 list). Which is the top one today, and 2, and 3, and 4. The SM can add information (as can the PO), but please allow the rest of the team (not the SM) to decide the priorities. Even if they are wrong, they are right.

Attacking One Impediment

Now, the whole team spends the rest of the time working on the top impediment. Here are three things the team can do together:

1. Devise a solution together. This is a phrase the Ken Schwaber likes. They take the responsibility to define how to fix the top impediment. Again, some impediments cannot be fixed, but can only be mitigated or the impact can only be mitigated (reduced). This might take some time. We might include root cause analysis (RCA).
2. Plan the execution. We figure out how to implement the fix — which steps, who should be involved. This might lead to the observation that the fix is costly, and maybe this isn’t the impediment with the best ROI.
3. Business Case. We work together to prepare a business case to take to a manager, and ask for a “yes.” A yes to some money or to getting some people to work on it, or a “yes” to allowing the change to happen.

Business Case or A3 Approach

We recommend that you use the A3 approach to Kaizen, but specifically that they business case be prepared much like an A3 report would be done. With the following sections: Problem, Solution, Benefits (from the Solution), Costs (of implementing the solution), Action Items (e.g., steps to be taken immediately after approval) and Measures (how we will measure after the fact that the solution actually improved things, or maybe not).

It would be fairly typical that the business case would not be perfect at the end of the Retrospective time-box. We expect the SM will move it forward and improve it, and then the SM (or the SM and the rest of the team) will present the business case to the right manager. If it is approved, it is up to the SM to keep driving it, so that the impediment is fixed quickly.

We want most fixes to be able to be impediment within two weeks, and by the end of two weeks we are already starting to accrue benefits (e.g., higher velocity). These comments raise a couple of points. First, the managers should be expecting these Business Cases. They should expect the team not to be good at presenting the business case, and the manager should start to teach the team how to prepare a better business case.

Next, the managers should be expecting to say “yes” and expecting change. My saying: “If you don’t change things, nothing’s gonna change.” So, now the team is helping the managers become effective.

Use common sense

Must you do the Retrospective in just the way I have suggested? No, of course not.

The first thing is common sense — use common sense. Follow my suggestions if they make sense for you (probably after you try them). Do something different if that will help your situation more. Remember that common sense is very uncommon.

Nonetheless, with my fairly specific suggestions I hope you see the purpose of the Retrospective in a different way. I think almost anyone on the team should want to come to a meeting that is useful, a meeting where we actually help fix our own problems to the top impediment.

Note: The next post in this series is here. 

« « The Sprint Review || The Artifacts » »