Great scrum masters and great agile coaches are a rare and special breed. They often do their best work behind the scenes, and they seldom want credit for a job well done. Instead, they’re most satisfied when they see their teams grow and succeed. In many ways, it’s like watching our kids grow up. They started as a collection of individuals and mature to a self-organized, effective, and efficient team. So what qualities set apart the good agile coaches and scrum masters from the great ones? I thought I’d try to answer that question today by way of several biases.
Today, I wanted to write about some flavors of a retro. For example, how do you guide a team that doesn’t want to address the elephant? However, I realized something was missing. How can I tackle the flavors when I haven’t discussed some facilitation fundamentals? So let’s get back to the basics of retrospectives.
- It’s always about them. Never enter the retro knowing what items the team will improve for next sprint. That’s not your decision; it’s theirs. A good scrum master will have ideas of where the team should grow. A great scrum master will let them find their own way there. Which leads me to my next tip.
- You create the container; they create the conversation. Most of the time should be spent here as you prepare for the retro. It’s your responsibility to find the right containers that allow the team to have the best discussions. It’s here with my retro flavors that I take a deeper dive in future blog posts.
- Practice good retro structure. Esther Derby has an outstanding model, and she writes about it in her book Agile Retrospectives. The idea is that the conversation initially diverges with a growing list of ideas and then ultimately converges into no more than three items that team agrees to implement the following sprint. If you don’t have time for all five stages, choose your stages wisely to take advantage of the team’s time. You’ll see the stages titled in the visual below.
I think I learned agility differently than most. I learned it through osmosis. Through my leaders, I learned what agile looked like, what behaviors were ideal, and which were counterproductive. The first time someone accused me of being “agile,” I was confused since I had no idea that’s what it was called. Where most can paint a beautiful picture in words of what agile looks like, I was fortunate enough to see it in action and exemplified by some of the world’s most influential leaders. The only difference? We called it leading Marines.
I came to this realization after reading Corps Business by David Freedman where he wrote about the 30 management principles of the U.S. Marine Corps. He created his list after interviewing a number of inspiring Marine Corps leaders, and I was fortunate enough to serve under many of them during my 10 years as an intelligence operative and martial arts instructor. Freedman brilliantly describes the principles in simple and straight forward language, and I thought I’d share a few of his principles with you today. Let’s get started.
In my previous blog post, I wrote about data-driven experiments. Unfortunately, it lacked any practical application, and today I want to do something about that. But let’s get one thing straight first. This isn’t my favorite topic. Why? It focuses so heavily on data and so little on humans. When we get too wrapped up in data, we lose sight of the human dimension, and that’s bad. Never lose sight of what matters. That’s not you. That’s not data. It’s your teams. Keep this in mind when you run data-driven experiments.
Before I show you some of my own experiments, let me explain the questions I ask myself when building one:
- What problem (or behavior) are we attempting to solve (or highlight)? This is the heart of your experiment. Never lose sight of this. We will, and when we do, immediately bring it back to center as often as necessary.
- What data can we collect that addresses the question above? Collect this data and no more. The more data we collect, the more time it’ll take, and we risk muddying the focus. We also risk inundating our teams with too much data so it’s imperative pare it down to the absolutely minimum.
- Who will we share this data with? Honesty in your data is important. If the team feels that they will be judged by those in power, they may unconsciously game the system and manufacture the data we want or expect to see.
- How can we create simple view into my data? The simpler, the better. Consider the burn down chart. With just a few simple data points, it can inspire a great conversation. It’s these conversations that make for a powerful experiment.
Work In Progress (WIP) Experiment
Multi-tasking has a cost, and it’s often a cost that many teams overlook. In fact, this was one of my top 10 tips in a previous blog post. While I was a scrum master for three teams, I wanted to highlight how much work each team had open on every day of the sprint. Once a day and at the same time, we recorded the percentage of stories in progress by each team and created the graph you see below. Notice that I also included an “optimal” range. This range isn’t based in any science. It’s simply where my gut told me our teams should be. Here’s what they looked like after the first sprint of the experiment.