Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Rules for Better Retrospectives

Rules for Better Retrospectives

Leia em Português

This item in japanese


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:

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

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • The way we to retrospectives

    by Markus W.,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p