The following is an edited version of a post to the Scrum Development Yahoo! group made by Dave Barrett (CSM) (used by permission):
The ScrumMaster (Process Owner) role itself doesn’t automatically imply any degree of authority, although at times it does help when you need a little clout to clear some impediments or to negotiate with other departments. More than that, the ScrumMaster role does carry a responsibility to provide some leadership to the team. Even a self-organizing team needs leadership!
So I would say that it helps if the ScrumMaster has a little bit of
seniority over the rest of the team, it also helps if the ScrumMaster
approaches the role as a coach and leader, rather than as a supervisor.
On paper it looks like the ScrumMaster only has a few tasks:
1. Chair the Scrums, and make sure they happen each day. (The self-organizing team’s regular status meetings.)
2. Chair the Sprint (Iteration) Review and Planning meetings.
3. Produce the burndown chart. (An information radiator used to indicate the amount of work left in the product work item list and in the iteration work item list.)
4. Do the team’s “paperwork” – publish the Sprint Backlog (product work item list) once it has been set and so on.
5. Clear impediments brought up during the Scrums.
In reality, the ScumMaster needs to do a lot of other things. There’s all of the leadership stuff, keep the team happy, productive and motivated. There’s the political aspect, keeping other groups and
departments happy and out of the team’s hair. As the in-house “expert” on Scrum, you need to referee on points of procedure and theory. Often you need to champion Scrum within the organization.
Really, I don’t see a huge difference between the roles of Project Manager and Scrum Master. Semantics mostly. Project Manager almost seems to imply a “command and control” approach, Scrum thrives best
without that. I wouldn’t make a junior programmer a project manager, nor would I make him a Scrum Master.