Rules for Better 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.

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:

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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.