Where do you draw the line? How do you make sure the scrum master doesn’t become a dumping ground for work?
Here are my thoughts:
This is an interesting question that I’ve been pondering and I don’t believe the answer is a simple yes or no (maybe it is and I’m just not looking at it from the right perspective). I think it depends on the situation and where you draw the line between impediments and team responsibilities. It’s always important to keep responsibilities in mind when examining impediments because what the impediment is and what you need to resolve as a scrum master could be two different things. You don’t want to overstep your bounds.
I’ll illustrate with an example I’ve seen in the past. The team identifies they need test data in order to complete verification of a user story and raises this as an impediment. The scrum master then spends time with the team to understand what test data is needed and why without it the story can’t be verified. He or she then works through whatever enterprise process is required to request test data.
My issue with this example is that I believe it’s the team’s responsibility to get the necessary test data to verify and complete the story. If the scrum master does it for them then he or she is taking away their responsibility and not maintaining accountability with the team. The scrum master needs to address the teams lack of knowledge and understanding on how to request test data. That’s the underlying impediment the scrum master should be solving.
Obviously removing impediments is part of a scrum master’s duties but it shouldn’t be done at the expense of removing accountability and responsibility from the team (as outlined in my example above). It’s a delicate balance and one that people need to be careful of.