Why hold retrospectives if ideas don't get implemented?

Email Notifications

SHARE
Request to reuse this

I've written and spoken frequently about the many issues with holding infrequent lessons learned sessions. The good news is that many practitioners now recognize that it is much better to discuss and implement improvement ideas frequently over the life of their projects than just at the end of a phase or the project as a whole. This applies both to projects which follow a predictive life cycle as those following an adaptive one, with the main difference being the frequency at which such reviews occur.

Retrospectives are an integral part of the Scrum framework but conducting such reviews regularly is core to most flavors of agile.

However, that doesn't mean they are well performed.

To understand why, let's draw a parallel to project risk management.

Teams might do a reasonable job at identifying risks, assessing them and coming up with risk response recommendations for the higher priority ones. Unfortunately, often times those risk responses never get implemented. This might be the result of response owners not understanding how important it is to implement the responses in a timely manner, a lack of quality in the risk or risk response descriptions, a high tolerance for accepting risks, or just a generally low level of organizational project risk management maturity.

The same appears to be the case with retrospectives.

I ran a one week poll in PMI's Project, Program and Portfolio Management discussion group on LinkedIn soliciting feedback from the group members on what percentage of improvement ideas had actually been implemented from the last retrospective which had been held within their teams.

Of the 42 members who answered my poll, just under two thirds of them indicated that fewer than 25% of the improvement ideas were implemented. Not a single member indicated that over 75% of the ideas had been implemented.

There are many possible causes for this including:

• The team comes up with too many ideas and is unable to prioritize which should be implemented
• The team identifies issues but no ideas to address those issues
• The team lacks the psychological safety to run experiments to test the top ideas
• The system surrounding the team impedes their ability to implement ideas
• Most of the ideas fall outside the control of the team and they are unable to convince stakeholders to implement those ideas

Regardless of the cause, given how frequently retrospectives are conducted, if so few ideas are implemented, this is a significant waste of people's time.

Perhaps teams should being to apply the old agile cliché of "Stop starting, start finishing" to the improvement ideas...