Hey Scrum Master I have an impediment:
As a Scrum Master it’s quite common to hear someone saying: “That’s an impediment. You are the Scrum Master, make sure that you remove this”. This impediment can vary from a defect build, a conflict in the Scrum Team or even a defect coffee machine.
But what is really an impediment? An impediment is anything that blocks or slows the team from delivering releasable product increments. The Development Team and the Product Owner should try and solve those impediments. For example, if a build is broken, or if there is conflict within the Development Team, or if there is low collaboration between the Product Owner and the Development Team. The Scrum Master can can coach the team in doing so and facilitate the process of removing those impediments. However, if an impediment is outside the team’s ability to solve, then the Scrum Master should step in and remove it.
I have an easy to follow “walkthrough” when it comes to dealing with impediments:
Step 1: Think if this is a true impediment or just something temporary. Step 2: If this is an impediment, wait. Think first whether the team can solve it by itself or not. Step 3: If the team cannot solve it by itself, then the Scrum Master should help them to remove it. Remember, help them, don’t remove it for them. You are not the team’s servant, you are the team’s servant leader.
A typical “Scrum Master’s impediment” would be something that requires a change in the organisation’s existing policy. For example: The Development Team is not allowed to configure their build and the latter has to be elaborated by a different team. This profoundly blocks the team from delivering releasable increments and therefore the Scrum Master has to make this issue transparent and then work with the organisation and the responsible people so that the necessary changes can be made. I had a similar situation and as a result, a member of the “configuration team” joined the Development Team. Still not ideal, however change is slow and constant.
How do we track impediments? There is no specific time for that. Impediments should be tracked and made transparent anytime during the Sprint. A preferred point for me is the Sprint Retrospective, where the team focuses on the process and how it can be improved. If you are a Scrum Master you should facilitate the discussion and create the necessary safety for fruitful outcomes. And by fruitful I mean a list of impediments. From there, I create an impediments’ backlog; visible and transparent to everyone. The owners of the impediments should also be clear and because it is a backlog, make sure that it’s prioritised based priority and/or severity.
If you want to experiment further, here is another idea: an impact risk matrix. It looks like this: the vertical axis reflects the impediment’s impact -as long as it is not removed- and the horizontal the effort needed to be removed. Logically, start with the lowest hanging fruits and the ones with the highest ROI. 
For example, the team identified the lack of automated testing as an impediment, or the lack of collaboration between the Development team and the Product Owner. How easy is it to remove such an impediment and what is the potential impact if not removed? On top of that, I like to measure the impediment’s cycle time (i.e. how much is it needed to remove an impediment). Maybe the impediments have deeper roots and you should investigate further to find the real cause.
Remember: Ask the team first and Inspect ’n Adapt.
NoAgile 