Achieving the Goal of a Retrospective

Some teams seem to approach Retrospectives without a real drive to succeed.  Or so it seems.  They just use it to ‘talk.’  About the ‘good, the bad, the ugly’ as I sometimes tease.

Now, talking can be helpful.  Still, we can usually do better than this.

What is the goal of a Retrospective?  Well, I think it should be to notably improve the Team.

Sometimes, to help them have more fun. And other times to become –‘more productive’ is the usual phrase.  Becoming more productive should be a point of pride for the Team.  That they are good, and they are always getting better.  That mere fact should be part of what makes them happy.

How do I mean more productive?  Well, I am ok with two ideas.  One: we are delivering more business value. Two:  the velocity has increased, and we are not by working harder or longer.

So, how do we make this happen?

Well, there is no end to the ideas about the details of the Retrospective.  And we need to have many ideas to be creative about improving ourselves.

Let me suggest two basics.

1. Starting Stuff
2. Attacking one impediment

By ‘starting stuff’ I mean something fairly brief.  Let’s say about 15 minutes.  This section might include the following.

• Some appreciations or ‘yea us!’ or ‘let’s continue’.  Some good news of things going well.
• Eliciting some ‘bad news.’  Mostly what we want are new impediments, or impediments not previously identified, or indications that old impediments are more important than formerly thought.
• Getting a brief ‘demo’ from the ScrumMaster. The SM explains what he did the last Sprint. Which impediments he worked on and fixed.  And how much improvement was made (eg, the velocity went from 20 to 21).
• Deciding on the top impediment as a team

Note that additional impediments are only useful if it or they are within the ‘top 20’ impediments. Anything less important is probably just distracting for the team.

Also, the top impediment is often entirely obvious to everyone on the team. But not always.

There are lots of detailed techniques for doing this starting stuff.

Also, note that I have implied (and am now saying) that the Retrospective is not a general talk session.  It is not for general ‘bitching and moaning’.  It is not to ‘answer questions’ or just to ‘look back’ or simply to gather ‘lessons learned.’

Prioritize. And make a significant improvement.

Work on the top impediment.

Will we always choose the real top impediment?  No.  But we pick the one we think, when worked on, will give us the most benefit (improvement) per unit of cost.  (Ok, a few other factors might also be included.)  We make our best guess at the top one.

Three things the Team might often do in the Retrospective to attack the impediment.

1. Devise a solution.
2. Develop an implementation plan for the solution.  I do not mean a detailed Gantt chart or WBS. No.  An approach, some steps, and identify who is needed, the basic activities, a sense of who needs to do what so that it can get done.
3. A business case.  An A3. To get the manager to say ‘yes’.  To money, to providing people, to just approval that the change can happen. Maybe to all 3.

One or more of these 3 actions might normally take up the bulk of the Retrospective. Actually fixing the impediment is done outside the Retrospective.  By the ScrumMaster, or by the Team, or by someone outside the Team

Expect to get measurable improvement (eg, better velocity) in the next sprint.  Usually. That means what you attack is small-ish and do-able in that timeframe.

I think if you follow this advice, your team will find the Retrospective more useful, and will become more productive overall.  Enjoy the happiness of being more successful.

 

« « Enabling Specifications || The ScrumButt Test (1): Iterations must be timeboxed » »