ScrumMasters Are In A Paradox
One of the core responsibilities of a ScrumMaster is to foresee and remove impediments to the team. So naturally, any time an impediment is raised, a good ScrumMaster's first thought is to remove that impediment.
One of the main practices of a ScrumMaster is that of servant leadership. So naturally, any time something comes up, a good ScrumMaster wants to step in and assist the team themselves.
Discussion and literature about agile typically discuss alternatives to agile as command and control (in terms of big up front or phase based planning). The command and control nature of these alternatives contrasts with the intent of the more enabling ScrumMaster role.
Technology companies build and
promote tools allowing "developers to focus on development." So technical
ScrumMasters may follow that same course.
Combine removing impediments, servant leadership, and reducing command and control practices; and ScrumMasters are inclined to serve the team by removing the impediments themselves.
But what happens when the team becomes reliant on the ScrumMaster? The servant leader has just become the impediment.
ScrumMasters Are In A Paradox--But Who Isn't?
The ScrumMaster should always first look to see what can help the team complete their commitment. At times, the ScrumMaster will themselves remove impediments, complete tasks, and coach the team. At other times, the ScrumMaster will ignore the impediments, let tasks go uncompleted, and let the team work it out.
Similar to other leadership roles, the ScrumMaster's role is to guide and protect the team. A team navigating a project needs to gain the experience and skills to support itself for the life of that project. Therefore, a ScrumMaster needs to determine when to remove an impediment, and when to leave the team to remove it themselves.
Teaching People To Fish Is Nothing New
Part of removing impediments is to enable the team to complete their current Sprint. More of removing impediments is to continually improve the team to allow them to remove the impediments themselves and then prevent the impediments from occurring.
The Real Impediments
So what are the real impediments? Which impediments should ScrumMasters remove themselves? How does the ScrumMaster balance servant leadership with helping the team succeed?
Let's look at each of these questions:
The real impediments are those that don't happen often. They are the ones that are looming ahead. They are the ones caused by specific individuals at specific times. The real impediments are not the work that people don't want to do. They are not the manual work that the team has not yet automated. They are not the compliance or regulatory administrative work the team faces.
ScrumMasters should remove these real impediments. Big items affecting the team's agility should be attacked by the ScrumMaster to bring change. A ScrumMaster should facilitate the onboarding of an automation team member and framework as removing a foreseen impediment. A ScrumMaster should not typically make all the security requests or do all the administrative work disliked by team members. A ScrumMaster should instead coach the team on the best way to streamline the security request.
A ScrumMaster should have no problem performing the smallest or largest of tasks to help the team. Learning all the processes, all the policies, and all the practices of the team should be on the ScrumMaster's short list. But where there is pain, let the team feel it--they will want to automate the pain away over time. Where there are lessons to be learned and improvements to be made, ScrumMasters should step in and show the team members which tasks are designed to help them grow.
My favorite fake impediment:
Team Member: "I sent the email and haven't heard back yet. So I'm blocked."
ScrumMaster: "What did he say when you called him to ask?"
Team Member: "Well, I didn't call yet."
ScrumMaster: << Walked over to the next building, up the stairs, down the hall, and asked for the answer. Then walked back to the team member.>>
ScrumMaster: "He didn't see the email, but your answer is ..."
In this case, the ScrumMaster should take the team member along and show how simple it is to get an answer.
Next Steps
ScrumMasters' next steps are to return to their teams and take a second look at the global and task impediments they're working on. Which ones are pain that no one wants to do? Give those back to the team and let them improve upon them. Which ones are good opportunities for learning or growth? Identify some specific team members that could benefit and walk them through the process--let them shadow the process of removing that block. Which ones are not on your impediment board? ScrumMasters, go find those and work on them yourselves.
