The Empirical Retrospective Approach

This post was written for MGS by Brian Milner

People often ask me in class about the Scrum Master role. Where should they focus first to make the best impact on their scrum teams? With all that Scrum Masters do, it can be difficult to know where to start.

I want to mention that the Agile Values & Principles are just as much a key to an organization’s success as the Scrum Values are. I want to explain how to be a Servant Leader rather than a top-down manager.

But I usually start by telling them to focus on facilitating highly effective retrospectives.

Scrum Masters are responsible to teach their teams the benefits of the Kaizen mindset—that is a mindset of continual improvement. Retrospectives are the key to unlocking this. Too often I see teams that want to skip retrospectives. Why?

They’re bored. Their Scrum Master leads the team through the exact same retrospective every sprint. Put yourself in their shoes. It’s sleep-inducing to run the same process every time but it’s too much work to come up with a fresh process each time.

What a Scrum Master needs is a pattern to use each sprint while swapping out the components of it for each retrospective. The Empirical Process is just that: a very simple, highly effective pattern to conduct your retrospectives.

Empiricism is the idea that we learn best from experience. In fact, the words expert and experience have the same root. You wouldn’t want a doctor to say, before a big procedure, “You have nothing to worry about. I am an expert in this procedure. Well, I am legally obligated to inform you that I’ve never done this procedure before, but don’t worry. You’re in good hands.” You’d run screaming from that hospital!

We want our experts to have done this a thousand times, to have seen it all, and to know what to do even if something goes wrong. And that’s the power of empiricism.

The Empirical Process has three steps that give us a great roadmap to being more successful in our retrospectives: Transparency, Inspection, and Adaptation. When followed in this order, each step provides a powerful tool to examine your sprint and determine your next steps.

Transparency

The idea with transparency is to put all your cards on the table and hold nothing back. Sometimes we hide how we really do our work for fear that someone outside our department or team will use it to blame us somewhere down the road.

Hiding our errors keeps us from learning from them, though. We need to do the opposite and be completely open about how we do our work.

So our retrospectives should begin with being transparent. First, what has happened with the action items we identified in the last retrospective? Then focus honestly on what actually happened in this past sprint: where were the pain points? Where did we succeed?

If everyone feels safe being open enough to share what really happened, everyone on the team can honestly see the failures and the successes of the sprint.

This is data collection. Catalog what happened from the team. Ask them to brainstorm, and make sure everyone has an equal opportunity to voice their thoughts and concerns.

If you think the team doesn’t feel safe to speak their minds, provide anonymous methods for them to share their concerns. This is where exercises such as Starfish, Sail Boat, or even the basic Plus/Delta can be very effective.

Inspection

Inspection is about going deeper. Often when we consider issues, we don’t take the time to dig deep enough to get to the root cause. Then we end up solving the symptoms but not the disease. It takes time to think through issues, to fully examine the causes and the ramifications of events that occurred in our last sprint.

Since we have been transparent, we can dissect the way things really work. We hold up the magnifying glass and deliberately inspect the details of our successes and our failures.

As the saying goes—some attribute it to the philosopher George Santayana—“Those who cannot remember the past are condemned to repeat it.” Retrospectives then require us to look deeper to find the source.

In this phase we want to get to the root cause. WHY did things happen as they did? Exercises like 5-Whys or Fishbone Diagrams can be helpful here.

Adaptation

Adaptation is at the core of what it means to be truly agile. After all, we embrace change! You cannot be agile and stay in the same spot. As a counter-example, even the most dysfunctional of families is able to be transparent and to inspect. They can point out the problems with no problem.

But adaptation is the real trick: committing to change the things that led us to these issues in the first place.

The real point of a retrospective is to commit to your next steps. What must be done to prevent this from happening again? Or what must be done so that we can take even more advantage of what we’ve discovered?

Sometimes you’ll uncover a problem so large that you won’t be able to solve it in just the upcoming sprint. That’s OK. If it’s the biggest issue for the team, you do need to commit to at least taking steps to resolve it in the next sprint.

And time can be a magic ingredient: when your team’s issues revolve around personality and emotions, these steps can require a great deal of personal introspection and work.

Your mission in this phase is to walk away with actionable items to resolve your biggest issues. A previous version of the Scrum Guide told us to place these directly into the next Sprint Backlog, thereby avoiding the need to be prioritized. Since the retrospective is attended by the entire scrum team, the product owner has contributed to deciding these action items.

Skipping the Product Backlog and moving straight to the Sprint Backlog says that we place a priority on continually improving as a team.

As you prepare for your retrospectives, then, I invite you to remember to be transparent, to inspect, and to adapt.

If you use this simple three-step pattern, you can mix and match the exercises you use as long as they accomplish these three things. You’ll have a proven recipe for productive retrospectives worth every team member’s enthusiasm.

Please share your thoughts where this post was originally published, on the Mountain Goat Software blog.