Skip to content

No time for reflection? Try a 5 minute retrospective

November 12, 2008 by Peter Stevens

I recently started managing a new project. As such projects are by definition “challenged”, I like to start with a retrospective to find out what to focus on and earn some initial respect from the team. In this case, the team is working fervently to get a release out, which should happen in a month, so everybody is under stress and no one wants to take time off for “diversions”. A heartbeat retrospective takes 1 to 2 hours, depending on the size of the team. How do I get the team to do a retrospective under these conditions?

Ken Schwaber applied an interesting technique at his plenum session in Stockholm. At the time, I thought it was just a nice device to help conference attendees get to know one another. Ken would pose a deep, thought provoking question to the audience. Then he would ask everyone to discuss the question for 5 minutes with two or three of their neighbors. Then he would go around the audience and ask the spontaneous teams what answers they came up with.

The first meeting with the team

Back to my new project: On the first day, I spend the morning meeting with all the managers (team leader, 3 levels of line manager and the product manager), and in the afternoon, I am being introduced to the team; well actually, to half of the team, because the rest of team is overseas. Assembled in the room are 4 developers, 2 testers, the lead developer and 3 managers.

We went around the room and made introductions. By now I have realized no one will give me an hour or two for a retrospective, so I asked the developers and testers, “I want to you to split into two groups of three, and spend 2 minutes to identify the top two factors we have to improve.” All of the managers jumped in and wanted to say something (which might be the subject of a future article about the challenges of moving to self-organization and servant leadership), so I reminded the managers that it was our turn to listen. The team split into two groups and prepared their post-its.

I asked for two items from each group, because I wanted to make sure we had at least two things to work on. After two minutes, each group presented its two points (two more minutes) and then we prioritized the list, for a total of 5 minutes.

What was on the list?

  • Communication between team members
  • Communication between groups (dev and test, local & remote sites)
  • Communication between business and development
  • Quality of the product

Communication was the clearly the word of the day, so this is where we started to work. We introduced a physical task board to make the status of work in progress visible to everyone concerned.

After the first Sprint

Ten days later, we still had the same problem - no time for a retrospective - but we did have the concept of an “après-scrum:” 15 minutes of time reserved for the team after the daily scrum, just in case if they need it. So after realizing that no one would agree to take an hour for a heartbeat retrospective, I asked the team to take 5 minutes for a quick retrospective during the après-scrum. The team agreed, so in groups of two, everyone answered two questions “What have we improved?” and “What do we still need to work on?” Each team got to present one answer to each question.

What role for the 5 Minute Retrospective?

I have now done two of these ‘5 Minute Retrospectives” - they are very lightweight, the results have been useful and they have helped us get moving in the right direction, even though we didn’t have time for “real” retrospective. It’s also easy to vary the questions so that the meetings don’t get too predictable (read: boring).

Does this replace a “real” retrospective? I don’t think so. The 5 Minute Retrospective is rather superficial: people don’t get to tell their stories, they don’t get patted on the back, and there is little room for alternative viewpoints. So if you need a quick analysis of the situation or you’re under a lot of pressure, it’s a great alternative.

How do you ensure that your team does regular retrospectives? Is anyone else doing lightweight retrospectives?

About the Author: Peter is an independent Scrum Trainer and Coach. His mission is to help you realize complex projects. He provides coaching, training and project management to help you get started with Scrum, save projects in crisis and make your IT operations leaner and more effective.

Originally from the US, Peter now lives in Zurich. He studied Computer Science at Colgate University, started his career at Microsoft, and is now a Certified Scrum Master (Practitioner). He speaks English, German, French and Italian. An Instrument rated private pilot, his current hobbies are sign language and Sudoku.

Comments

How do you get your team to do regular retrospectives?

November 12, 2008 by Ilja Preuss (not verified), 1 year 17 weeks ago
Comment id: 1991

How do you get a woodworker to regularly sharpen his saw, even though he has so many trees to cut?

re: Lumberjacks

November 12, 2008 by peterstev, 1 year 17 weeks ago
Comment id: 1993

You don't. When he notices that his axe is dull, he will sharpen it himself.

These leaves the question open, how much time passes between the point when you think he needs to sharpen his axe and then point when he actually sharpens it.

Cheers,

Peter

lumberjack -> software developer

November 13, 2008 by Ilja Preuß (not verified), 1 year 17 weeks ago
Comment id: 1995

For me, the follow up question seems to be: How do we get software developers to recognize that reflecting on and improving their process will make them go faster? And is that even the case?

The time to propose changes

November 13, 2008 by peterstev, 1 year 16 weeks ago
Comment id: 1996

The time to propose changes when the team is ready and able to accept them.

Right before a release is a difficult time to convince a recently converted waterfall team to try out major new ideas. This is how I stumbled on the 5 Minute Retrospective. Once the release is out, the team (and management) should be more receptive.

And once they are working in sprints, then the pressure is much more constant, the rhythm established, and then making time is much easier. The other problem with retrospectives is keeping them fresh, so that the team doesn't get bored with the process after 3 or 4 sprints, but that is a another issue...

Cheers,

Peter

keeping retrospectives fresh

November 14, 2008 by Esther Derby (not verified), 1 year 16 weeks ago
Comment id: 1997

You make a good point..the time to propose changes is when the team is ready to accept them. And that's one of the purposes that retrospectives serve. The team identifies the changes that they believe will help them and that they have energy to work on.

As for keeping retrospectives out of a rut, some ideas in these two articles:

Seven Ways to Revitalize Sprint Retrospectives
http://www.estherderby.com/articles/revitalizesprintretrospectives.htm

Making Retrospective Changes Stick
http://tinyurl.com/6lypq4

Cheers!

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.

Best of AgileSoftwareDevelopment.com