Rules for Better Retrospectives

Posted by Chris Sims on Mar 01, 2010

Sections

Process & Practices

Topics

Team Collaboration ,

Agile Techniques ,

Agile

Tags

Continuous Improvement ,

Best Practices ,

Retrospectives

James Carr recently published a list of five rules to help improve the effectiveness of retrospectives. The rules are based on his experiences in hundreds of retrospectives, both successful and not.

James' five rules are:

Retrospective Belongs to the Team

This means that it should only be attended by the team and only the team can pick a goal and how they’re going to follow up on them.

James feels that this is the most important of the five rules. James' experience is that management that interferes with the teams' retrospectives is likely reducing the effectiveness of the process.

Don’t Let It Become a Whine-fest

Nothing is worse for a team then to spend an hour in a room listening to each other bicker without any from of constructive activity… it will leave the team feeling down rather than up.

The point of the retrospective is to make improvements, and therefore problem-solving activities should be given more focus.

Activities Are Better
Based on James' experience with retrospectives that included activities, vs. those that took a more 'no-nonsense' approach, he finds the former approach much more effective than the latter. He finds that activities keep people engaged and help break down communication barriers.

A popular source for retrospective activities is Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen. Half of the 10 chapters are dedicated to exercises and activities.

Pick Only One Goal

Limit your Work-in-Progress as a team by selecting one (and only one) goal for the team to work towards during the next iteration.

While it may be tempting to try to fix all of the issues discovered during an iteration retrospective, it's better to focus on one at a time. The idea of the sustainable pace applies to making improvements, just as it does to the rest of the team's work.

Follow Up

Failing to follow up can leave the team with a slew of goals they never complete or superficial goals that only kick some dirt over the issue.

Nothing undermines the retrospective process like failing to do anything with the results of the retrospective.

Those inspired to improve their retrospectives by James' article may also want to read these previous articles on InfoQ:

• Tips to Improve Retrospective
• How To: Live and Learn with Retrospectives
• Key Elements of a Successful Agile Retrospective: Preparation and Participation

In your experience, what is most important to the success of a retrospective? Leave a comment and share your experience.

1. Back to top

   The way we to retrospectives

   by Markus W.

   We just ask ourselves (=the Team) three simple questions which lead automatically to the point
   
   - "Events during the last Sprint?" (sometimes this question can be skipped)
   Anything that happened (negative and positive) which is worth it to mention.
   e.g. Attacks or major changes by the Product Owner during the Sprint, great improvement of the velocity, etc.
   
   -> "Conclusions?"
   What have we learned from the events or from the Sprint in general?
   e.g. Product Owner must not interrupt the develover during the sprint, improvement in velocity caused by improved communication, etc.
   
   -> "Actions?"
   What are we going to do about the things we've learned/concluded in the future?
   e.g. Scrum Master will talk to the Product Owner about interruptions, put a sign on the wall to remind us to keep on communicating, etc.

   Reply

• Older >