Better Retrospectives

In Scrum (and in life), we have periodic retrospectives.  In Scrum, we have a time-boxed Retrospective meeting once each sprint. Why?

The main reason is to be more productive without working any harder.  Put another way: mainly to remove impediments. I hear about far too many Retrospectives where we have a lot of fun bitching and moaning. Then the action is none or very weak. (“Ok, I agree to stop blowing my nose when we’re having a conference call.” )

Some suggestions:

1. Get more creative about identifying the biggest impediments.

It can be ANYTHING that is slowing down team velocity.

As an aside: Velocity is something important, but not everything.  If you’re going 90 mph in the wrong direction, you’re still going in the wrong direction, for example.

I find it is hard for most teams to put the biggest impediments on the table.

So, we must challenge ourselves. “If we want to double our velocity, what do we have to change around here? Let’s assume for a moment we could change anything.”

2. Pick the biggest impediment.

The Team might swarm around this question for a few moments. If they are not decisive, then the ScrumMaster must help them be.

What is the main priority? What, if fixed or mitigated, would improve our velocity the most?  OK, then we can add cost-benefit analysis, and say: What, on a bang for the buck basis, will lift velocity the most?

3. Work out a proposal on the biggest one.

A proposal could be a business case or action plan, or a few other things.  Basically: either get a good idea how to fix it, or a good idea how to convince the right manager to help fix it.  Maybe help means “give us some $.”

I particularly like the Lean A3 approach to kaizen.  (Removing impediments is basically kaizen.)

4. Fix only one thing at a time.

Don’t get several improvements in flight.  Usually not a good idea; too confusing.  Focus and get one over the  goal line.  Then work on the next one.

5. After the Retrospective, the SM must make sure someone is always taking action.

Every day.  It could be the SM, it could be the Team.  In fact, the effort by the Team could be as much as one user story.  It could be by people outside the Team (even consultants or contractors from outside the company).

6. Report back to the team the results from the actions.

I think teams are generally realistic.  That is, they will not be surprised if the SM finds it hard to get things to change.  Who knew the team would actually like to hear about the results.

Hearing about the results closes the feedback loop. And the results will be good sometimes.

And hearing the results will remind them why they care about the Retrospective, and help everyone make it a better, a more useful meeting.

***

Which of these suggestions helps the most?

 

« « The Biggest Problem || Release Planning with Business Stakeholders » »