The Retrospect – Even Better Next Time!

I have already asserted that without feedback, there can be little or no improvement. And we need to provide and receive feedback to improve ourselves and our team members.

This post is part of our Scrum-series, and we have arrived at the fifth and last activity in the Scrum-process (according to our stripped down definition of Scrum) — namely The Retrospect.

Purpose

The smartest people I know, rarely do anything without seeking various forms of feedback on the results. I believe this urge for feedback and evaluation to be a core reason for their journey on the highway of constant improvement. The Retrospect facilitates this journey of constant improvement for Scrum-teams.

How

The Retrospect is time-boxed to 3 hours. The team members in turn all answer the two simple questions

  1. What went well during the last Sprint?
  2. What could be improved in the next Sprint?

A list of all answers is constructed during the Retrospect by the Scrum Master (his role being that of a secretary), and the team itself will prioritize the list by importance. Remember that the more issues (even the more negative) that are brought to the table, the better. If the team can find nothing to improve, this is a certain sign of an unsuccessful Retrospect. As humans, we’ll always be imperfect, but the most obvious sign of imperfection is believing that everything is just as it should be. Ensuring that there is continuous improvement is more important than only evaluating how good we already are.

If there are several suggestions for improvement, I would recommend not addressing all issues immediately. Pick just a few to improve for the next sprint. The actionable ones (like “We need more stable test-environment”) are put into the Product Backlog for prioritization. Normally they’ll receive a high priority. The non-actionable ones have served their purpose once they have been mentioned and discussed (such as “Commit your source code daily”). Just having mentioned something is often enough to fuel the team members own thoughts and visions about how to improve themselves and the process. Don’t force yourselves to break everything down to concrete tasks.

Identifying and articulating what went well during the sprint is of course just as important. It is a motivational mechanism that let you see the effects of past improvements more clearly.

Be brave

It is perfectly normal human behavior to shield ourselves from feedback we assume not to be entirely positive, or that might even be negative and require more improvement from of us than our current capability allows. However, in order to improve we need to lower our defenses, and allow ourselves and our accomplishments to be evaluated. It’s vastly better having heard suggestions for improvements and doing nothing about it, than never having heard it at all. Be brave. Listen to it. In the end, you’ll benefit from it.

You’ll see that the more negative issues that are discussed and evaluated in The Retrospect, the more improvements there will be to commend in the next retrospect.