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 working software. Impediments could be related to technology, process, or interactions. 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.
In my experience, there are five common problems preventing teams from tackling impediments.
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 challenges is limited. Their ability to take advantage of opportunities is limited.
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 Scrum Training Courses, I explain that constraints help maximize self-organization. However, the majority of “constraints” I have come across are usually not constraints but rather recommendations or best practices. People assume they are constraints and don’t question it.
Some constraints have exception processes if you have good reasons for doing something differently or not at all. For example, an organization I coached required the use of a specific testing tool. But if you did not think it was the best tool for your team and your product, all you had to do was document an exception and explain how your team was doing testing and capturing results.
I recently heard an example at a conference of a team who actually 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.
Does your team have recurring impediments? Do the impacts of those impediments seem small or large?
For example, you have to fill out a form to get permission to access a database. This need arises about every other Sprint. It takes 10 minutes to fill out the form, and there is 24-hour turnaround. Not a big deal, right? What if you sometimes have to follow up to clarify the permissions needed because the form isn’t that clear. Whoever has to deal with this usually gets frustrated and vents to the team while trying to resolve it. But at least they take turns having to deal with it, and it only happens about once a month.
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?
For example, the team is manually regression testing every Sprint. As the product grows, it seems this activity takes up more time. Defects are being discovered at the last minute, and they don’t usually get fixed until the next Sprint. Yet, implementing test automation is a huge undertaking. The team doesn’t feel they can do that now because delivering business value is most important.
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:
Waiting until an impediment becomes urgent (i.e. all forward progress is blocked) will typically be a huge impact. Try not to do this.
If we schedule every working hour of every Development 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. Removing impediments is part of the work. Here are a few ideas to acknowledge this and encourage this.
A Scrum Master’s responsibility is to help the Development 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 role of an Agile Manager is a big topic. All I will say here is that helping remove organizational impediments when a team needs support is one of their responsibilities. 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-organizing Development Team will know which impediments they need to address, when to address them, and when they need support from outside the team.
Check out the rest of the series on Getting to Done:
AGILE SOCKS is a registered trademark of Agile Socks LLC. Other marks used herein are the property of their respective owners. For more information see Trademark Notice in Terms & Conditions.