Rules for Better Retrospectives
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.
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.
The way we to retrospectives
- "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.
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.
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.