Thursday, December 22, 2011

Responsibilities of the SM

The responsibilities of the SM are a long list:

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

If you can do all of the above while "developing code".. More power to you, but don't compromise the above tasks for speed i.e. getting more code done, because you may compromise the work of everyone in the team instead.

This article is by Mike Beedle and borrowed from

No comments:

Post a Comment