Get the Data to Remove the Really Hard Impediments

I was looking through some old notes and found this question from a LinkedIn group.

“Has anyone experienced where impediments are raised, but you (as a Scrum Master) do not have the power, control or autonomy to remove these impediments?  If so, what have you tried to overcome this?”

This old question got me thinking about the last post on Seven Wastes in Software Development.  Nothing is more destructive to Scrum than letting clear and obvious waste persist in the organization.  Waste encourages cynicism and leads to oblivion.  ScrumMasters constantly have to be on the look out for waste and work hard to stop cynicism from taking root.  They do this by working to help others see the impediments they have grown comfortable with and finding ways to help other remove the little things that annoy people and the big ones that cause real productivity losses.

It is true that a ScrumMaster usually has no power or authority to remove impediments.  If they did have this autonomy to root out waste they would no longer be called a ScrumMaster, but would be a manager.  A manager, by definition, has power and autonomy to make changes.  Being a manager is fine, but a ScrumMaster is not a manager with a new title.  So often times ScrumMasters will partner with people who have this power to get things done.  Also, keep in mind that many impediments can be removed by the Team themselves.  A ScrumMaster almost always should encourage the Team or the Product Owner to fix their own problems.  A ScrumMaster should never do something the Team or Product Owner can do themselves.

So how do ScrumMaster’s help managers, Team members and Product Owners remove impediments?  By bringing visibility to problems experienced by the Team to the people who have the authority and autonomy to do something.  In my experience working with Teams, managers and decision makers, this three step pattern works very well when you have no authority or power in the organization.

1. Get the data that shows a business impact of the impediment.  If there is no business impact, then no one will care about the impediment.  I also have found that it is very hard to argue against data that shows how an unresolved\unremoved impediment is causing an impact on the performance of the Team or the organization.  I am OK with either quantitative or qualitative data.  Obviously, quantitative data is easier to argue from and you can make good cases for change based on qualitative data, too.
2. The next step is to socialize the data with the managers and Stakeholders that have the authority to remove the impediment.  Tell them why you are researching the problem, share your data, your interpretations and then ask for their advice.  They have probably have been grappling with the impediment for a long time and you may not be the first person to bring this issue to them.  In addition, lots of people can have different interpretations of the data and often come up with different solutions based on their experience, perspective and biases.  That is fine with me, as long as we have captured the attention of the Stakeholders, we can create some forward movement on removing the impediment.  The key here is to create dialogue and show that you want to be part of the solution.
3. Finally, ask for permission from the Stakeholders to implement a fix.  If you have unilateral authority to make the change (good) or they may ask you to partner with someone (just as good).

Do not be surprised, but occasionally people do not want an impediment removed.  Sometimes the right people or resources are not available to remove the impediment.  Other times, the decision maker does not have the time or energy to devote to making a change.  If the impediment is large, it will take time and energy from the decision maker which they might not have at their disposal.  I have also seen that Stakeholders might want the impediment removed, but do not think the ScrumMaster is the right person to lead up the effort.

If a Stakeholder or manager chooses not to implement a fix, that is their decision.  I would then work with the Stakeholder to find out when you can come back and talk about the issue again – two weeks, three Sprints or six months.  It does not matter when, but you need to communicate that to the Stakeholder that you are 100% dedicated to removing the impediment when the time is right.  Respectfully, you must communicate that a delay does not mean the problem is going away and that you will be back in from of them to talk about this issue again in X amount of time.