The Case for Retrospectives

Posted in Agile, Scrum, Leadership, and Management - 0

Even with all the good reasons to do retrospectives, they are still the first thing most teams cut when they’re feeling pressured to perform faster, deliver more, or increase quality. What’s ironic is that they are cutting the one thing that could help them both increase their velocity and quality.

New Scrum teams sometimes drop retrospectives because they fail to understand the purpose of the meetings—the why. Dropping retrospectives can cause catastrophic problems—glitches that are relatively easy to solve when they are new can stagnate, fester, and grow into larger issues. Common issues that manifest themselves when the retrospective is cut include drops in quality, a variety of failing tests, lowering of team morale, and more. Dropping the retrospective removes the team’s opportunity to reflect. Without reflection, the team gets lost and wakes up one day to look in the mirror at a very different picture. It’s almost like grooming yourself—most of us shower or brush our teeth daily because, if we don’t, problems start to manifest. Without learning and continuous improvement, teams will fall back to their old habits and wonder what happened—and they will usually blame Scrum for their failure.

Retrospectives drive people to change their behavior over time. To ensure that your retrospectives yield results, make sure that people understand some basic principles:

  • The retrospective is for the team and no one else. This means don’t go blabbing about what someone said.
  • Build confidence through small changes. Taking on too much at one time can build frustration. Taking on small, calculated changes and accomplishing them builds confidence.
  • Own the changes. The team is responsible for its changes, not just the ScrumMaster. Get people involved in driving the changes identified in the retrospective.

Retrospectives are not limited just to sprints. In fact, it is common to see retrospectives after a release, a large unexpected issue, anything. Remember why we do them: so that we can stop, look at the situation, and then make adjustments. In a postmortem, everything has already happened, and our ability to effect change is gone. In a retrospective, we usually are still actively engaged in the project. Consider adding higher-level retrospectives for releases (say every three months) and in case of sudden environmental changes like unexpected outages, scaling up for larger teams with more people, , and creating occasional retrospectives between the team and the customers. The customer retrospective can help you identify areas for improvement between the team, the customer, and the product owner.

Once team members understand how effective retrospectives can be, they won’t ever consider cutting them again.

Read more about Retrospectives and other helpful topics in my new book, The Scrum Field Guide: Practical Advice for Your First Year.