In a previous post describing challenges to creating a Done Increment, I identified impediments as one of those challenges. More specifically, NOT removing the impediments makes it difficult to create a Done Increment. Scrum Teams will always face impediments because the work is complex and dynamic. The question is whether we tackle those impediments or live with them.
An impediment is anything that is slowing down or blocking a team from delivering quality Increments of value. Impediments could be related to technology, process, or people. It is easy to get overwhelmed by the expectations of delivering more product features faster and feel like there is no time for implementing improvements. However, removing impediments helps improve workflow and can result in higher quality and easier delivery of enhancements in the long-term.
5 Challenges Tackling Impediments
1 - The team is not empowered.
I talked about team empowerment related to the challenge of team ownership. Empowerment comes into play again here. When a team cannot make decisions about how they do their work, their ability to improve is limited. Their ability to adapt to change is limited. Their ability to take advantage of opportunities is limited.
- Make the Developer accountability explicit. They instill quality as they turn the Product Backlog into Increments of value. And as professionals, they are expected to do this to the best of their ability. This means they must manage and improve upon their processes, tools, and interactions to be more effective in delivery.
- Coach management on how to create an environment of empowerment.
- Question how we do things. This could be processes or practices that the team owns or something that exists in the organization. Asking bold and outrageous questions can help your team step into their power.
- Ask for forgiveness, not permission. A Scrum Master can be the one to show courage first in "taking power" if the team does not yet feel their own empowerment. A Scrum Master should be prepared to protect the team when they do exercise empowerment.
2 - We confuse constraints and assumptions.
I have seen people assume they have to follow certain processes or use specific tools because it is a constraint in the organization. When I teach Professional Scrum classes, I explain that constraints help maximize self-management. However, the majority of "constraints" I have come across are usually not constraints but rather recommendations or best practices.
Some constraints have exception processes if you have good reasons for doing something differently or not at all. I recently heard an example of a team who worked with regulators to influence policies that they saw as impediments to software delivery. How awesome is that!
Question everything.
Help your teams come up with bold and wild ideas. What if we could do anything we want to solve this problem? What would that look like?
You might actually be able to try out those crazy ideas.
3 - Impacts of impediments are not understood.
Does your team have recurring impediments? Do the impacts of those impediments seem small or large?
Is your team putting off process or tooling improvements because they are a large effort? Or maybe there is a price tag that we are worried won't get approved?
Is your team putting off knowledge sharing or training because there isn't enough time? Or maybe they don't want to be perceived as less productive.
I have two suggestions to help clarify the impacts of impediments:
- Look beyond the "blocking" impediments. Many impediments are not stopping us from working but rather slowing us down and preventing us from delivering the most value. I call these "anchors." We may be able to push on, moving forward while continuing to drag them behind us. Eventually we get tired, and they slow us down further.
- Quantify impacts in terms of cost and business impact. Make it visible. Put it on a chart. Show the trend.
- How much time are we spending dealing with an impediment? How frequently is this impediment occurring? A technique I have used in the past is the Waste Snake.
- What is the quality impact? For example, are the number of defects discovered in production increasing or decreasing? What is the cost of fixing a defect in production versus fixing a defect found during development?
- What is the impact to the team's flexibility?
- How is the impediment affecting morale? Are people leaving because they are unhappy with the impediments? What is the cost of hiring someone new? (I'm taking this to the extreme, but it is a valid situation. People leave dysfunctional organizations. Tolerating impediments is a dysfunction.
Waiting until an impediment becomes urgent (i.e. all forward progress is blocked) will typically be a huge impact. Try not to do this.
4 - Planning too much in the Sprint.
If we schedule every working hour of every Scrum Team member during a Sprint, we are almost guaranteed to fall short. Furthermore, the team will likely feel there is no time to resolve impediments. We must recognize that improvement is part of the work. Here are a few ideas to acknowledge this and encourage this.
- Stop creating arbitrary deadlines and fixing scope. The pressure to deliver specific functionality by a certain date can cause teams to fill a Sprint with Product Backlog items and push off the improvements they needed to improve their effectiveness. Scrum Masters and Product Owners can help protect the Developers from this pressure and work with those outside the team who may be creating this pressure.
- Make impediments visible and an input to Sprint Planning. Sometimes the Developers and Product Owner need to actually see impediments to keep them in mind during Sprint Planning. If the impacts of the impediments are understood, the next step is to make them visible and consider them inputs to Sprint Planning.
- Get your Product Owner on board. The Product Owner's accountability is to maximize the value of the product. If the product is not scalable, enhance-able, or maintainable, the Product Owner is not going to get much more value out of the product (or it will come at great expense). I have worked with Product Owners who are fierce advocates for removing impediments to the Scrum Team's continuous improvement.
- Don't be afraid to talk about some impediments in the Sprint Review. Some things are best to handle with the Scrum Team only in the Sprint Retrospective. However, organizational impediments or impediments that require investing in the Scrum Team may make sense to bring up in the Sprint Review. You have a wide range of stakeholders in attendance, and they may have influence to assist with these impediments.
5 - Management is not engaged in removing organizational impediments.
A Scrum Master's responsibility is to help the Scrum Team remove impediments they cannot resolve themselves. However, a Scrum Master should not feel they have to do this on their own. Sometimes the Scrum Master just needs the Manager to provide cover or support for their efforts. It is also important to recognize that a Manager can often provide knowledge, insights, and influence the Scrum Master does not have.
The Scrum Master and Agile Manager should be working closely together on the impediments that will require organizational involvement and support.
In summary, a Scrum Team tackles impediments in order to improve effectiveness in delivering valuable software. Teams must be empowered to resolve impediments. The impacts of impediments should be made transparent. Teams must take the time to resolve impediments. A self-managing Scrum Team will know which impediments they need to address, when to address them, and when they need support from outside the team.
If you think one of these problems is affecting your team, pick a technique and try it. Let us know how it goes.
Check out the whole series on Getting to Done:
- Encouraging Team Ownership
- Improving Team Collaboration
- Creating Good Sprint Goals
- Balancing Emergence and Delivery