Scrum Without Removing Impediments Isn't Scrum

Before Scrum, my friend’s team waited an hour or more just to get on a test machine. They adopted Scrum and years later, they still wait. There are myriad other problems that have not been resolved. No wonder they don’t see the point of Scrum.

Scrum only works when we use it to address the problems that exist in our environment, and then work to resolve them.

Consider the basic principle that a Scrum Team is required to produce high quality working software (or hardware) at the end of every Sprint. Shippable quality.

Common Reasons Impediments Don’t Get Resolved

• Definition of Done¹ doesn’t exist, isn’t honoured, or isn’t published in a truly visible place (usually the Team room wall).
• Definition of Done isn’t frequently updated and improved until the Team is at least able to ship at the end of every sprint; preferably able to ship continuously.
• There are no Component or Feature Teams². Scrum doesn’t require Feature Teams explicitly, but it does require that the Team has a sufficient supply of skills that it can get a small vertical slice (not just one component) of software to truly done at the end of every Sprint. Component Teams, while legitimate in Scrum, increase the coordination effort required to get to done every Sprint.
• Pressure exists to deliver more every sprint. Many Teams feel a constant pressure to deliver significantly more than they’re able to. The pressure is so intense, that they constantly take shortcuts to try to meet the demand. Scrum was created to give the doers more freedom in deciding how much work they could achieve and how they could achieve it. It only works when the Team takes a stand and makes clear their capacity. Real improvement is only possible when the Team has sufficient slack to pause, reflect, and improve.
• Organizational impediments are not removed. For example, network issues between one office and another, coordination issues between Teams, or anything else that can’t be resolved at the Team level.

In theory retrospectives are Scrum’s built-in mechanism for catching the problems that are stopping the team from making improvements. In practice, the same teams that are struggling to solve their own problems, also struggle with the retrospective.

Make Impediments Visible

Part of the problem is the lack of visibility into the impediments. Problems that go unseen will never be addressed.

• Add a blocked column to the Sprint Backlog
• Add a blocked decorator to individual items in the Sprint Backlog or Kanban board. My favourite version counts the number of days an item has been blocked.
• Capture Cycle Time data and make it visible outside of the Team. It is often the fastest way to show that one person has become a bottleneck.
• Use Cost of Delay or other models to show the impact of the impediments in real terms.
• Canvas peer teams to see if they have similar impediments, it’s easy to get a change made if it’s not just your team that’s affected.
• Create an Impediments backlog and post it somewhere visible to everyone.

My favourite example: I put a team’s Impediments backlog on the wall outside a VP’s office. He asked why I’d put it there. My response was that these were problems the team couldn’t solve and needed his help with.

At the end of the day, the Scrum Master is accountable for ensuring that the impediments are removed. When the impediments are internal to the team, this can be as simple as finding out if team members need any help in resolving them. When the impediments are outside of the team, the Scrum Master needs to create visibility and awareness of the impediments, including talking to peer teams and management. The hard part is doing it without blaming anyone, which is a skill we spend real time on in Certified ScrumMaster training. And when those impediments are seen repeatedly and not resolved, the team learns that Scrum changes nothing. That is exactly how you end up with people who don’t see the point.

Scrum is a problem-finding tool, not a problem-solving tool.

Your organization has to solve the problems that Scrum highlights, for it to work effectively. Since Scrum doesn’t solve the problems for your organization, you’re not actually practicing Scrum if you don’t follow through and resolve the issues that it finds. Instead, you’re practicing Mechanical Scrum.

My friend’s company wasn’t failing at Scrum. They were failing to evolve. Organisms that stop evolving eventually die out.

Image credit: Kanban board © Agile Pain Relief Consulting (August 2026), built in Kanban Zone.