Retrospective Failures and How to Avoid Them

Posted by Mark Levison on Jun 04, 2008

Community

Agile

Topics

Agile Techniques ,

Collaboration

Tags

Retrospectives ,

Coaching and Mentoring ,

Facilitation

Most of the writing about Agile Retrospectives focuses on basics of how to conduct them and what formats you might use. Patrick Kau is taking the opposite tack, he asks how they might get misused and then makes suggestions on how to avoid these problems.

So far he's described a variety of problems

• All Talk and No Action - the team is left with the feeling that the same problems are raised over and over again with no effort being made to solve them.
• All Action and No Talk - the corollary, some teams are so focused on taking actions that they don't consider all the viewpoints. The result they solve the wrong problems.
• The Format Becomes Too Repetitive - If the same format is used time after eventually team members will become bored and tune out during the retrospective.
• Conflict of Interests - when a stakeholder acts as facilitator some will focus only on the issues that they find relevant as opposed to the issues raised by the team.
• Controlling the Conversation - the facilitator can take control of the retrospective dispempowering the team.
• The Facilitator Did Not Prepare - if the facilitator is hasn't prepared by considering: audience goals, how far to look back, prepared a timeline, written an agenda and involved the right people - then retrospective won't meet the needs of the team.
• Poorly Formed Action Items - inexperienced facilitators will sometimes allow the team to create broad overreaching actions that can't be achieved in a single sprint.

So how do we go about solving these problems? Patrick has a few suggestions. When it comes to Controlling the Conversation and Conflict of interest, he recommends:

...focus on the process, and less about the content. Your goal should be to ensure everyone has an opportunity to build the shared story, everyone has an opportunity to add their insights and everyone has input into the final solution. Do not push for the solution you think is best, ... Make it clear when you are expressing an opinion as a person-with-a-stake. Empower the group with a mechanism that gives you feedback when they feel you are directing the conversation too much.

On spicing up the retrospective format, the book Agile Retrospectives: Making Good Teams Great gets the nod from a number of sources. In addition Nathan Henkel suggests:

...start with specifics. Questions like “I remember you were planning on using a table lookup to improve performance–how did that turn out?” Sometimes questions like “what went well?” leave everyone mentally stunned.

Sumeet Moghe has a number of ideas on creating actions that will get completed:

• Use the SMART acronym to drive out action items (Specific, Measurable, Achievable, Relevant, Time Boxed) ...
• Dont take the onus of driving the actions yourself ...
• When reviewing the action item, have the owner give an update and see if the group is satisfied ...
• Remind the group that improvement is a collective goal and there's a shared responsibility towards it.

Finally Bas Vodde uses the approach of breaking down large long term tasks into small manageable goals:

I ask the team to generate all actions in a specific format: Long-term goal:  Have test automation on acceptance-test level. Now-Action:  Pete will automate one test using Fit

This format helps the team consider a long-term goal for every action. It also helps them create very concrete actions to move the team a step closer to the long-term goal. The now-action has to be one that can be implemented in the next sprint and must be something the team can accomplish itself.

• Older >