Have a Question?


Contact us and we’ll respond promptly.


ScrumMasters are not Task Masters

by Darian Rashid 24. March 2010 20:01

Series: Agile Roles and Responsibilities

It always bewilders me to think about the amount of teams out there who designate the ScrumMaster as a ‘Task Master’. In these teams, the ScrumMaster’s role is often seen as that of an administrator. This ScrumMaster schedules, plans and runs the meetings, including the Daily Scrum.    His job is to make sure all the perceived overheads of the iteration are completed so that the team can focus on their “real” job. “Come around and get our hours every day so we don’t have to input them,” the team may say. “And while you’re at it,” they may add, “be a dear and handle any interruptions that come our way, would you?” However, this is a mistaken notion.

ScrumMasters are called what they are for one very simple reason: They own the process of Scrum.  They have one of the most complex and difficult jobs in the development organization: To create and maintain the processes by which we work. In short, they need to be change agents. 

I don’t mean to imply that ScrumMasters don’t work within the team. On the contrary, they work intimately as a part of the team to help create and adapt processes within the team. However, they aren’t the ones that manage the team and the team’s meetings and events – the team itself does that. It is perfectly fine for the ScrumMaster to perform those activities when working with a newly formed team but with the understanding that those are owned by the team and will be transitioned to the team as soon as possible.

What, then, should the ScrumMaster be doing once those items are transitioned? Everything else that falls under the ‘own the process of Scrum’ category. This includes working with Product Owners just as intimately as the team, to help with release planning and tracking, bridging the gap between the Product Owner and the team. This also includes working with existing management to solve deeper organizational issues that is beyond each team. Finally, they are responsible for working with other ScrumMasters to maintain a coherent process across the organization. In the end, a well balanced ScrumMaster will work in equal parts with the team, the Product Owner and the organization. 

This may be a good time to mention that the role of the ScrumMaster is a full-time one, but that is another blog entry.

Tags: ,
Categories: Agile Leadership | ScrumMaster | Process

Comments

5/17/2010 8:51:57 AM #

Michael Kirby

Here's a question for you to ponder:

What's the difference between a scrum master, a manager, and a leader.  I'm less interested in the non-overlapping parts of the jobs. (so I get it that a manager does HR stuff, and a scrum master does backlogs and the like).  

Much more interesting is what happens when the Manager (a former technical leader and scrum master), the current design lead (and former scrum master), and the current scrum master (a former technical lead and perhaps former manager) Disagree on something.

I think fundamentally the role has to be separated from leadership.  Each of the three individuals exercise their abilities to lead outside of their functional jobs.  An organization with a cooperative culture will allow the leadership qualities to rise to the surface, then consensus is reached, and then the individuals roles kick in and the manager "does manager stuff", the technical lead "does technical lead stuff", and the scrum master does his thing.

A dysfunctional organization is the one where the manager gets his way because of his role, not because of his leadership ability.  Similarly with the technical lead and scrum master.  

Mike

Michael Kirby United States

Add comment


(Will show your Gravatar icon)

  Country flag

biuquote
  • Comment
  • Preview
Loading



Follow us

Follow AgileEthos on Twitter       Follow AgileEthos' RSS Feed

Recent Posts