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.
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.
It’s not often enough that I see teams experimenting. Well, that’s not entirely true. Most teams experiment by trying new techniques, by adjusting their process, or simply by trying something different. I’d call these anecdotal experiments, and they’re very valuable. However, it’s not these kinds of experiments that I want to talk about today. I’m focused on quantifiable experiments. Consider it a data-driven approach to analyzing team dynamics or individual behaviors. For me, this was borne from my affinity for the burn down chart. If used as intended, the burn down is simple, it’s useful, and it inspires a team to ask intelligent, focused questions. If my experiments do the same, I’ve succeeded.
Before I begin, I have a confession. I’ve rewritten this blog post several times now. Each time, it gets away from me so I scrap what I wrote and begin again. Why? Simplicity. I kept losing sight of it. Because of this, I’ve adjusted my approach. I intend to write this blog post in some rather broad strokes while my next will contain more context and examples of experiments I’ve run in my teams.
With my first broad stroke, let’s talk about some of the advantages of data-driven experiments:
It’s a powerful tool, and it’s a point of honor that a scrum master has no control, only influence, within a team. I prefer it that way, and I hope you do too. I recently reflected on how I conceptualize influence, and I realize that I operate in one of three contexts. Before I share those contexts, a caveat. Before my life as a scrum master, I was a Marine. I served as an intelligence operative and martial arts instructor for 10 of the most formative and adventurous years of my life. Even now, I still find myself using military language to explain my thoughts. In my opinion, it makes for a more vivid metaphor.
Frontal assault. When you know you won’t face much resistance, lay out your idea, explain what you’re looking to do, gain buy in, and execute. No subtlety is involved, and it’s usually the quickest method to implement an idea. However, use caution. Never let bias for your idea convince you that others will love it. If you conduct a frontal assault and find support is lacking, the losses can be substantial.
Rules of engagement: