Impediments

In the context of a Scrum team, anything that slows the team’s progress towards the Sprint Goal is an impediment. And since one of the primary responsibilities in the role as Scrum Master is removing impediments to the Scrum team’s progress, it’s important to have a clear understanding on this point.

All too often I hear Developers in Daily Scrum mention the same chunk of work 4-5 days running and say, “No Blockers.” Why is that? Experience tells me there is a heap of factors, but the biggest seems to be that we don’t have a common understanding of what an impediment is.

Understanding what is an impediment in Scrum

According to the Cambridge Dictionary, an impediment is “something that makes progress, movement, or achieving something difficult or impossible”.[1]

But in Scrum, it goes further. And until our teams recognize what impediments are, they can’t get resolved. For example, these are all Scrum impediments:

• Low bandwidth connection while working from home
• Email interruptions
• Slack or MS teams scrolling messages at an alarming rate
• Interruptions - People outside the team asking for help (either other teams or management)
• Lack of information (e.g.. interacting with a poorly understood legacy system)
• Missing technical knowledge or skills
• Waiting for another team
• Waiting for a third-party vendor
• Team member out sick
• Access or permissions problems that prevent team members from accessing a server or making database changes
• Language or cultural barriers with an offshore team
• Poorly understood Product Backlog Item/User Story
• Low understanding how this Product Backlog Item fits into the overall product and delivers value to the customer
• Slow computer
• Frequent broken builds
• Poor quality chair or desk, small computer monitor
• Slow decision-making
• Changing requirement mid-Sprint
• Bottlenecks in the Team (e.g. worked piled in front of Business Analysts, Developers or QA)
• Too many cat photos in the team’s Slack stream 🙂
• …

Anything that slows the team’s progress towards the Sprint Goal is an impediment.

Spot the Problem

There are a couple of tricks and tips that I’ve found to help make impediments more apparent. First, change the word to “slowdowns” – it’s a lot easier to admit to being slowed by something,  than it is being impeded (which suggests stopped). Go deeper as the Certified ScrumMaster, and look at the Sprint Backlog or Kanban board to spot items that have spent several days in the same state (e.g. “In Progress”, “waiting for test” etc.). These items are likely impeded by something.

Is work piling up? Sometimes bottlenecks or missing skills create impediments. Too many teams don’t even notice that they have bottlenecks, but they’re great indicators of areas where cross-skilling will be a benefit and make the team more efficient.

How to remove impediments in Scrum

The Scrum Guide says the Scrum Master can act as an impediment remover by “causing the removal of impediments to the Scrum Team’s progress”. This sounds comically obvious and simple on the surface, and yet it gets misinterpreted. Too many teams think that it’s the Scrum Master’s job to directly remove the impediments. “Scrum Master, I’m out of coffee (or sticky notes), can you get me more?” This is clearly ridiculous. A good ScrumMaster helps the team learn to remove their own impediments. They aren’t a magician who waves a wand and does it all for you.

Even if the Scrum Master were to remove all impediments, the team would only learn that when they had a problem the Scrum Master would solve it for them. The Scrum Master would turn into a babysitter – an unwelcome prospect.

So what’s effective? This is where the ScrumMaster role can have a huge beneficial impact by promoting self-organization, and striking a balance between firefighting problems that crop up and preventing the impediments in the first place.

When there is a problem, I encourage Scrum Masters to ask their team member(s):

• what they already tried toward solving the impediment
• if they asked the rest of the team for help
• whether they ever had similar problems before and what worked in resolving those

Tougher than it looks

If all of the above has been explored and the impediment to the Scrum team still remains, the problem is probably beyond the capacity of the team to solve on their own. However, before running around problem-solving, there is still more work for our Scrum Master to do, to be able to fix anything effectively. They should explore:

• Is this the first time we’ve had an impediment like this?
• If this is a repeated impediment, why has it reoccurred? (Hint: often because the last solution was a band-aid fix.)
• Do we need to address this immediately or can the challenge become a learning opportunity for the team?
• What else is going on here?

That last point is probably the most important, but hardest, one to deal with. Instead of using the popular but weaker techniques of 5 Whys or Root Cause Analysis[2], dig into Systems Thinking to find the underlying issues. Use this understanding to address the real issues in the system, and not just the surface-level problems.

The Scrum Master role when impediments occur

The Scrum Master shouldn’t solve impediments on their own. It’s important that they give the team autonomy and let them self-organize. Encourage them to take ownership and find their own solution to many impediments.

When an impediment is one that the team can’t solve themselves, then the Scrum Master’s responsibility is to step in. Review team history for similar impediments. How were they resolved (or not)? What were the underlying causes? By identifying the real problem, and not just the surface issue, the impediment can be removed permanently, and not affect the team’s progress again in the future.