Key Elements of a Successful Agile Retrospective: Preparation and Participation

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.

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.

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.

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.

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.

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 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.