Sometimes we need to ask the same question in a different way to get a different response or to get at the information we need. What is getting in the team’s way? We ask the standard daily stand-up question, "Are there any impediments?" We hold retrospectives and reflection workshops to prompt the team to reflect on what could be adjusted. Yet the responses aren’t always inspired. Here’s an exercise to add to the Scrum toolbox that can spark a higher-quality discussion. I call this the Runner, Hurdler, Steeplechaser exercise.
I'll explain the exercise using the track and field metaphor. Imagine that our environment is like an Olympic running track. It has a flat surface that’s well marked and cushioned. It’s laid out in a nice, organized pattern. As someone who works in this environment, uses this running track, and either experiences no noteworthy impediments or experiences some level of obstruction, which of these three field events do you think best represents your experience?
- Are you a runner?
- Are you a hurdler?
- Are you a steeplechaser?
If the running track is clear, with nothing in the way, you're a runner. You can just run. If there are some small impediments that you can get over easily, so that they don't affect your stride much, you're still a runner. If the running track is littered with small to medium impediments that slow you down but can be overcome with time and effort, then you're a hurdler. If the running track is more like an obstacle course, you're a steeplechaser.
The intent is to reflect on the environment, not individual performance. We want to identify technical or business environmental factors that create noteworthy impediments. We are not asking for people to comment about how fast or capable they are. From my experience, you may need to reiterate and remind participants of this point more than once.
Finally, the point of this question tool is to increase the visibility of impediments. I've found that the question, "Any blockers?" is not inherently bad, but it doesn't always work. In fact, I’ve seen it fail fairly often.
We should be allowed to change up our questions, right?
Scrum cofounder Ken Schwaber has reported having regrets about the three questions he suggested for stand-up meetings. He's known to have said that if he had to answer the same three questions for the rest of his life, he'd probably go crazy! (Alistair Cockburn, an Agile cofounder, knows Ken well and has recounted this anecdote several times recently.)
This is not a new-question exercise; it strongly resembles the usual questions we tend to ask in Lean/Agile settings. At the core, it has the same intent, which is to cast visibility on the things that slow people down and impede their progress. This is vastly different from suggesting a change to cadence. It's not a new meeting. It's not a new artifact. It's well within the bounds of Scrum. So, you can ask it and still retain your consistency and discipline.
Why are teams not talking about stuff that gets in the way?
Here's where more survey data would be nice. In the absence of data, by simply dipping into the experience pool we can flesh out three reasons why teams don't talk enough about what gets in their way.
First, it may not feel safe to explain what gets in the way. The last person to press about impediments beyond the team itself may have met with resistance or may have been removed.
Second, it may seem overly obvious or pointless. There’s no hope that the team can adjust things outside its control, so people stop trying. Some environments are so overwhelming that people give up trying to address the impediment. Some teams aren’t given enough slack to do anything about the environment. Maybe past answers led nowhere, so it seems pointless to keep sending the signal.
Third, it’s not that criticism is unwelcome, but someone poisoned the well through negativity, and now people avoid the topic to avoid getting labeled as the Doug or Debby Downer of the group.
These reasons may all sound familiar, but there's a fourth reason that may not sound as common. I think it is an important reason nonetheless. The team and organization may have a hard time learning about and knowing when to invest in efforts to remove impediments (automated setup of development environments, for instance). Sure, if it were free to remove impediments, then let them be discussed all the time. But since they're costly to remove, it's harder to manage them. What's more, it's not easy to know how to become effectively organized to do that kind of work. It stays out of sight because it stays out of mind.
The blockers-type questions are meant to make all these kinds of issues visible so that people have more options early enough to make adjustments. So, if the question tool being used doesn't do that, then it's time to reevaluate and find what does work. The intent is not to ferret out everyone's deepest, darkest secrets with ferocious intensity in every meeting — not at all. Rather, the intent is to keep a nice, productive conversation going that will eventually result in a nice, clear path for people to work in, so that they can contribute with fewer obstacles in the way and be happier at work.
What do we do with the new information?
Here's where I think SAFe makes an important contribution that is not articulated much in Core Scrum. The contribution is the team's ability to label work as either epics
, which create business value, or enablers
, which create ramps or clear the path in creating business value.
I've seen teams that are highly geared for epics but often in desperate need of doing more enabler work. This isn't always an issue that arises from the team itself. There are companies that consciously or subconsciously decide to not invest in enabler work and just "pay" for it by getting teams to work 60-hour work weeks instead. The variants are all over the map. In other cases, enabler work is tolerated, but it's not factored into the system, so it seems like a necessary evil or just something bad to do.
Regardless, I suggest reviewing the literature on SAFe for enabler work, and review what SAFe recommends for product owners in how to approach enabler work. This comment will make more sense after you have done this, but I'll add a suggestion that isn't mentioned in SAFe (to my knowledge): Consider having an architect or tech lead assume the product owner role for some enabler work, where he or she would clearly be in a better position to define the requirements and assess the resulting quality of the work.
I endorse the SAFe recommendation to suggest allocating effort on enabler work. Otherwise, just get everyone, including all the business, product, and program people, to buy in to the idea that it's normal, customary, and essential to invest in enabler work regularly. In other words, you may want to allocate 20% of total effort, or some other percentage that works for your environment, for enabler work — to bake it into the planning process.
Alternatively, to assess whether there’s any enablement work that should be done during the upcoming sprint, you may want to add this item to your list of sanity checks or sprint planning objectives. For instance, you may ask during sprint planning, "Is there enablement work surfaced earlier that we will need to invest in during this sprint?"
It’s imperative that if meaningful ideas are drawn from the impediment-related questions, some clear, concise effort must be made to make things better. Otherwise, people come to doubt the continuous improvement processes.
This is an imperfect tool, and that makes it just like all the other tools we've got.
Just as every tool doesn’t work perfectly for every application, this alternative question tool isn't guaranteed to work all the time either. If you have some more tools to make important impediments visible or uncover the need to invest in enabler work, please do share with the community.