Responsibilities of the ScrumMaster

A common question in the Scrum community is whether the SM (ScrumMaster) should only take the responsibilities of the SM, or should he or she also take development tasks.

Let's translate this question into a tradeoff question:  should we prefer the stability of the team provided by a good ScrumMaster, or should we opt for a marginal speed given by the SM taking some development tasks, and if so how many.

In my experience, the right answer, depends on the environment.  In some environments the SM can perform tasks, in some others is too risky.

For example, if the development team is developing applications with a complex architecture in a challenging domain, doing work through multiple Scrum cells some of them which might be distributed, with a set of fast changing set technologies, a highly political environment, and working with a “little trained” PO  – I would not recommend having a “coding SM”.  It would be too risky.   However, if the team is working on a single cell co-located Scrum cell with small or medium complexity, average technology complexity and/or change, and a reasonable PO, I might be much more inclined to have a SM that is also developing some code – but with the understanding that their SM responsibilities always have higher priority.

But what exactly do we trade off?

We can answer this question by looking at the responsibilities of the SM:

PROCESS:  Responsible for the entire Scrum process - Leader and motivator about doing Scrum:  

•       ensures Artifact quality

•       helps and coaches Roles to do their job: product owner,  customer, developers

•       ordering of activities, meetings, time-boxes

•       sets up, conducts and facilitates ALL meetings

•       ensures Engineering practices are followed

•       Ensures the Team has a good social context, a good environment, and it is SWARMING!

•       Enforces ALL rules

•       Promotes ALL values: transparency, honesty, courage

•       Insurance for “doing things right.  Intervene only if necessary!

TEAM: Flips between Coach, a Watchdog, a Mentor and a Project Manager, Rep to Management

•       Recommends or finds initial members of team

•       Responsible for team balance:  how many BAs, developers, testers, etc. of what kind?

•       The Scrum Master is responsible for setting the team up for success

•       Removing the barriers between development and the customer so the customer or the user directly drives development

•       Ensuring team actually did what they said they would do: checking testing reports, etc.

•       Balancing the team workload – e.g. pass work to early finishers

•       Shielding the team from outside disturbances

•       Removing Impediments and resolving issues

•       Promoting creativity, collaboration and knowledge sharing

•       Improving the lives of the development team e.g. flexible hours, flexible days, payback for heroics, etc.

•       Improving the productivity of the development team in any way possible: training, tools, system-level things

•       Improving the engineering practices and tools so each increment of functionality is potentially shippable

•       Promote team pride

•       Organizes Celebrations after releases or sometimes after Sprints

CUSTOMER: Teaches the customer how to maximize ROI and meet their objectives through Scrum

PO: Responsible for training and keeping ongoing communication with Product Owner (good PB!)

ADMIN: Maintaining the Sprint Backlog and producing Sprint Burndowns

•       Posting the Sprint Burndown as Visible Status:  Wall, Wiki, email, etc.

•       Ensuring Scrum Board gets updated

•        

MANAGEMENT: representative to team for management

MULTI-TEAM: Participating in the Scrum of Scrums such that both how their team affects other teams, and how other teams affects his team are understood, if no other team member is available

•       Coordinating participation of their team in either the “big room” Sprint Planning Meeting, or in a staggered Sprint Planning Meeting understanding dependencies, or coordinating with architects when they exist

•       Coordinating participation in the Sprint Review Meeting, both independently and with the rest of the multi-team, the latter is specially important in releases to production where many dependencies exist

•       Coordinating with integration Sprints when they exist

•       Coordinating integration issues with other Teams

•       Working with their team or theme PO and with the CPO (chief product owner), to ensure their teams can choose portions of the Product Backlog (usually though themes)

•       Coordinating with their individual teams on dependencies or modified work found at the Scrum of Scrums

So from the risk management perspective having a SM working for the Scrum team protects the productivity and stability of the entire team.

If a SM can do all of the above while “developing code”, more power to him or her, but my advice would be to not compromise the above high-priority tasks for a marginal velocity increase that may compromise the work of everyone in the team instead,

- Mike Beedle  

Enterprise Scrum Inc.