Scrum Master Responsibility : Removing Impediment for the team vs being a middle man

Question

As per the scrum guide, the scrum master's responsibility towards the team is to remove the roadblocks. But what extent should he go? I am not sure if the SM should go any extent and (maybe even) become the middle man and do all the communication.. approvals.. etc.. to help the team?

I will try to explain with example else it will become very tough for me to explain.

E.g. Team needs to certify the current application supports Windows Server 2017. They figure out that this needs creation of new server(getting approval, discussing the need to IT&S team) and then setting up the application for further testing.

In the above e.g I drop an email to the head of IT&S requesting for approval and once a Jira Ticket is created in IT&S Kanban Board and tracking starts. However, if there is a delay or any question comes from IT&S, it gets directed/tagged to me and eventually I become the point of contact thereafter.. Is this right? The guide didn't says about the extent scrum master should go to resolve/help team members..

Answer 1

Facilitate Communications; Don't Proxy Them

In your specific example, the Scrum Master should function as a communications facilitator, not a proxy for the team. The Scrum Master often functions as a switchboard operator by:

• Helping team members to identify points of contact outside the team for collaboration and refinement of Product/Sprint Backlog Items.
• Helping non-team collaborators (e.g. customers or stakeholders) figure out which team members they can to collaborate with to develop or refine a Product Backlog Item.

Clearing impediments should be more about helping the team to help itself than it is about being "the face of the team." If you routinely find yourself communicating on behalf of the team rather than facilitating communications or promoting/clarifying/refereeing the Scrum process, then there may be a process problem with your Scrum implementation.

Caveat: Extending the Role via Working Agreements

As a Scrum Master, you should be encouraging the Product Owner and Development Team to take ownership of the process and craft their own solutions within the tenets of the framework. However, as a member of the Scrum Team, you are an active participant in the process, responsible for fulfilling your core role as well as supporting the the whole team's internal working agreements. Balancing the yin-yang of the coach/referee role with full-fledged team membership within a continuous-improvement process is what differentiates decent Scrum Masters from great ones.

As a full member of the Scrum Team, the Scrum Master can (and often does) take on process responsibilities collectively agreed to by the Scrum Team. This can include delegated authority from the Scrum Team or Development Team to represent their interests with line management and stakeholders, or within certain inter-team processes such as a Scrum-of-Scrums.

The subtle distinction here between speaking for the team as its chosen spokesperson with authority delegated by the team, versus unilaterally speaking as the team based solely on the defined role of Scrum Master, is very important to make. The former is empowering and in accordance with agile principles, while the latter is generally a project smell that indicates an immature agile process. However, it's more of an art than a science; there's a lot of gray area making this a "your mileage may vary" issue that will depend greatly on your project's unique milieu.

Answer 2

Well, the Scrum Master should help with impediments. You have given no indication that this is an impediment. What makes the email to the head of IT an impediment, unsolvable by the team themselves?

The Scrum Master is not the teams errand boy. If the team cannot do it themselves, then the Scrum Master is their escalation step.

If it is sufficient to remove a specific impediment and then hand it over to the team that's fine (for example the head of IT requires an accounting request ID that none of the team possess, it might be sufficient to acquire such an ID for the team and then hand the task back to the original dev). If the impediment is long-term, then I guess the Scrum Master needs to handle it until the impediment is resolved.

If you have the feeling you are just the middle man and relay mails and talks between two parties without doing anything yourself, then most likely it's not an impediment. They could just as well talk directly.

Answer 3

You're right that the Scrum Guide is rather vague when it comes to how involved the Scrum Master is when it comes to removing impediments.

Personally, I believe that the Scrum Master should, as much as possible, be hands-off for how the team works. The Scrum Master is a single individual. In some organizations, this person may be working as a Scrum Master for multiple teams. As such, it would be extremely risky for the Scrum Master to do a whole lot of work on their own. Instead, I tend to focus on taking a low level of responsibility for project success while taking on a high responsibility for growth of the team.

In an example like the one that you present, I would be doing two things. For the Scrum Team, I would be working with them to ensure that they know how to interact with the IT&S team - who needs to be involved, how to interact with them, how to track the work and make sure that it gets done. For the IT&S team, I would be working with them to ensure that they understand how the Scrum Team functions and, generally, how to effectively interact with the team. For both teams, I would work with them at a team and organizational level to improve the working relationships and interactions between the IT&S team(s) and the Scrum Team(s) to make sure that these interactions aren't impediments to either side.

Answer 4

It is not the responsibility of a scrum master to do all non-coding tasks.

Can this task be put on one or more tickets? This actually looks like two tasks:

• create new server (List in ticket's Definition of Done: approval gained; get requirements signed off by IT&S; server provisioned; server requirements validated as correct; ...)
• further application testing.

Tickets should not be just for programming tasks, or a significant proportion of development tasks performed by the team are not being tracked.