Key Elements of a Successful Agile Retrospective: Preparation and Participation

Posted by Vikas Hazrati on Sep 08, 2009

Sections

Process & Practices

Topics

Agile Techniques ,

Agile ,

Teamwork

Tags

Retrospectives ,

Continuous Improvement

Agile retrospective helps the team examine what went well during the past sprint and identify the areas of improvement for the future sprints. However, sometimes the exercise of conducting a retrospective ends up as a futile effort due to lack of preparation. Moreover, key members of the team end up either not attending or not participating.

Esther Derby mentioned the following reasons for a failed retrospective,

• No Preparation
• No Focus
• Failing to Gather Data
• One or Two People Dominating the Conversation
• Focusing Only on Impediments That Are Outside the Control of the Team
• Biting Off More than the Team Can Chew
• Choosing Actions the Team Doesn't Have Energy For
• Keeping a Separate "Improvement Plan"

She also mentioned that, conducting a retrospective in an organization where pervasive blame culture is rampant is a very difficult exercise. In such organizations, people are scared and reluctant to speak up. Effort needs to be spent in these organizations to prepare them in order to conduct an effective retrospective.

Steven M Smith talked about another scenario where the key members of the team might not be interested in the retrospective at all. This is especially true when retrospective is done as a routine task and then no action is taken on the outcome. Steve mentioned,

Mitch [a key team member] clearly sees the failures and would like to do something about them. But he sees retrospectives as an equally large failure. When he looks back on the his participation in retrospectives for failed projects, he sees a consistent pattern. Each retrospective would find that a root cause for the failure was insufficient or inadequate sponsorship. And in every case, nothing ever happened to improve project sponsorship.

Steve suggested the following points to engage team members and conduct a fruitful retrospective.

• Review the results from previous retrospectives against improvements in the current sprint.
• Gain the sponsorship of someone who has the power to do something with the results of the retrospective.
• Make time for a face-to-face discussions with Mitch and all participants before the retrospective.
• Ask each person, "What could prevent you from being fully present during the retrospective?"
• Be willing to make adjustment, such as rescheduling or changing more elements of the design, to ensure the highest level of participation.
• Review the retrospectives objectives and agenda with each person.
• Ask each person for suggestions about what would make the retrospective even better for them.
• Remind each person that if the team wants things to change it must show the data, its meaning and significance in ways that will compel the sponsor to respond.
• Ask each person, "Is there anything that I should have asked you that I didn't?"
• Tell each person how important their participation is to you personally.
• Say, "Thank you."

Steve further reiterated that, getting the team members to a retrospective by force would not solve the purpose. This would make them physically available though they would still be mentally absent.

Thus, in order to make a retrospective successful, the team needs to be present with adequate preparation and effective participation. The team and stakeholders should be prepared to take corrective action at the end of each retrospective. Conducting a retrospective without these ground rules is a waste of everyone's time.

1. Back to top

   span of focus in iteration v. end of project retrospectives

   by Esther Derby

   I agree that without preparation, participation, and commitment to change (which means time and resources, not just will), retrospective don't result in improvements.
   
   And, Steve and I are talking about two different types of retrospectives.
   
   I'm talking about retrospectives that happen periodically during a project, with a focus on helping the team improve their own capability. The assumption is that the team will stay together and have a chance put the improvements they choose into action.
   
   An iteration retrospective might focus on the team's technical practices, work process, or teamwork, for example.
   
   Usually, teams who do iteration retrospectives focus on issues that they control, or at least can influence (in which case, the action within team control is gathering data to make a case to the person who does have control). But even when the team can't change some organizational situation, they can change their response in that situation.
   
   Steve is talking about an end of project retrospective. The issues that come up during end of project retrospectives tend to span organizational boundaries and be beyond the control of one team.
   
   Clearly, it makes little sense to have a team hold an end of project retrospective--especially on a failed project--unless management is present, and comitted to learning and changing.
   
   But that's a different problem than lack of traction in an iteration retrospective.

   Reply

2. Back to top

   valuable advice

   by Jun Ran

   I think the most important purpose of the retrospective meeting is to find out something that the team can improve, or do better in next sprint. Of course this includes what can be improved by each team member himself. If each member in the team has improved, the team can do a better job.

   Reply

• Older >