How do you design a good Retro?

In a recent coaching conversation, our team’s acting Scrum Master asked “How do I make a retro plan for a ‘good sprint’?” So we explored the issue. The conversation we had was awesome! So I wanted to share the questions we used to dive deeper.

The first question was ‘what is a good sprint’? What makes it a good one? Perhaps it’s meeting all our sprint commitments. Maybe it’s delivering good quality code, or a sprint with no bugs. But Identifying what make a sprint good, helps the conversation progress. For my part, delivering on sprint commitments with acceptable quality is table stakes. They should be the average. So, a ‘good sprint’ is ‘Average+’.

You’ll note that the previous exploration centered on the Team’s own view of the sprint. Their process, and their actions are most visible to them. But if you look at the Scrum Guide, the goal of any Sprint is to deliver value to the customers. So what is a ‘good sprint’ from the customer view? Certainly delivery on commitments is desirable. But so is the actual delivery from the sprint itself.

With both these definitions of ‘good’ in mind, turn to retrospective. The Goal of the retro is enabling or achieving ‘continuous improvement’. Improvement on what? Here I’d argue that the improvement must be on the team’s average. Improving Their average quality, their average flow, or their average delivery etc. . Thus, the goal of a retro on a good sprint (Average+ type) would be to capture what was different this time. And then to integrate that difference so the average improves.

Now ‘what’ is a retrospective, at it’s base? While it’s definition is an event to inspect/adapt on the sprint. But that is not what it is. What it is , is a meeting. As a result, we arrive at a new understanding of the original question. Asking “How do I make a retro plan for a ‘good sprint’” is actually asking:
“How do I facilitate a meeting that can achieve those (Scrum) goals?”

New questions and refinements emerge from this understanding. But I’ll explore those in a future post.