ScrumMaster: A Role or a Title?

[article]

So, my answer to hiring managers is straightforward. In my perception, the ScrumMaster is not a role that any stakeholder can play. At work, we have a standard job description for a ScrumMaster that lists pre-requisites for knowledge, skills, and experience, but the most important part during the ScrumMaster interview process are the scenarios or situational questions that I ask. I do so to learn if these potential ScrumMasters are able to better understand how they make decisions, respond to difficult situations, resolve conflicts, and motivate and inspire their teams.

I have also witnessed multiple examples of successful teams that did not have a separate title for a ScrumMaster. In those cases, one of the team members would become a designated part-time ScrumMaster. I’ve seen a business analyst, development lead, or one of the cross-functional team members being labeled a ScrumMaster on a team. In these cases, the team perceives the ScrumMaster as one of the cross-functional team members, and the other team members eagerly relate with this person. In all successful cases, the ScrumMaster is a natural leader on the team, an effective communicator, and is respected by the team members for being knowledgeable and fair.

Is the ScrumMaster a Stepping Stone in One’s Career or a Career in Itself?
This question, so seemingly simple, raised a lot of concerns from the ScrumMasters I have dealt with throughout my coaching experience. If you work for a startup, you may be less concerned with your career progression. If you are a successful ScrumMaster working in a corporate environment and your colleagues are progressing up a corporate ladder, you may ask yourself some questions like the following: What is my next step? If I have been a ScrumMaster for three or five years, does that mean I am not making a good career decision? What should be my next career move?

Many practitioners think that the ScrumMaster is a role, so prefixes such as “junior” or “senior” are not applicable. There is no such thing as a “senior leader” or a “junior leader.” While this logic may sound appealing, I disagree.

If you are a permanent company employee in a corporate setting, titles matter. Titles reflect the level of experience, complexity of the job, and perceived employee contribution to a company’s success. Companies differ in the way they define ScrumMaster career progression. Some companies use titles to designate levels of ScrumMaster maturity (e.g. labels like junior ScrumMaster, senior ScrumMaster, or agile coach) or complement titles by departmental levels (labels like manager, lead, director, etc.), but in each case, it is important to have a known and communicated career path within organization.

In this case, the career path should have a set of clearly defined and well-documented requirements associated with each title based on experience, skills, certifications, role, the number of teams, coaching and mentorship responsibilities, and a number of other criteria that fit company’s existing structure, title designations, and staff hierarchy. Once there is transparency and a shared understanding of the levels, ScrumMasters can see their title as a career and not as a stepping stone to their next, more exciting assignment.

Having a defined career path for a ScrumMaster does not mean that a ScrumMaster is expected to move in this pre-defined direction. Nowadays, most advanced companies support their employees in so-called “lattice” career advancement versus “ladder” career advancement, as defined in The Corporate Lattice: Achieving High Performance in the Changing World of Work by Cathleen Benko and Molly Anderson. According to this book, the word “ladder” refers to a traditional (vertical) career progression, which relies on titles and hierarchies; however, the career landscape is changing. As organizations become flatter, work becomes increasingly virtual, collaborative, and dispersed. Careers zig and zag. As a result, a “lattice” (horizontal) career model is better suited for today’s global business in which employees do not need a vertical progression to be defined anymore. This includes moving to different roles within the same organization, learning new skills, and mastering adjacent (and in some cases, totally new) areas of responsibility. Many of the ScrumMasters I know moved into product ownership, product development, and even into executive roles within their companies.

Why, you will ask? Because the qualities I described in this article as being important for a ScrumMaster are the ones that define a successful business professional, from a C-level executive to a successful entrepreneur or an agile team member. A ScrumMaster is more than a role or a title, it is a state of mind based on a strong commitment to agile values and dedication to the team and its success.

Tags: 

User Comments

3 comments
Ben Linders's picture

A Scrum master is a role, preferrably one that multiple people from a team can take. My preference is to let the Scrum master come from the team, a part time role next to technical activities. When recruiting, I would focus on the mindset and skills of people to have people in your team that can do the activities that are needed to have a servant leader that helps the team to do their work.

My view is that to work effectively as a team (or in any other way), you need to pay attention to your process, your way of working. That is mainly what a Scrum master does, which should be only a percentage of his/her time. So for me it’s a role, not a function.

December 12, 2013 - 1:29pm
Skip Pletcher's picture

Perhaps this is a false dichotomy.  Scrum master is certainly, by definition, a role.  The team draws value from someone being designated as SM for a given sprint, someone to act as Scrum parliamentarian and to chase down impediments. 

Whether that is the same person from sprint to sprint or rotated among team members is a secondary consideration.  Whether some organizations decide to so specialize that SM becomes a billet with title(s) does not change the role.

I share your appreciation of the diminsihing value offered by a the SM role as a team (and its parent organization) mature with agile practices.  I also think we risk agility when we decide to specialize staff beyond what their own motivations and aptitudes require.

We disagree with respect to the inability to develop 'values and instincts' perhaps because I have seen civilians converted to warfighters through the development of just such traits.

December 18, 2013 - 12:08pm
Tom Mellor's picture

 

I don't agree that the ScrumMaster is the most controversial role in agile-based development.  That distinction could arguably go to Product Owners.  If you feel that ScrumMaster is just a title, then it is effectively meaningless.  Mike Cohn knows Scrum, for sure, and his opinion about the value and responsibilities of the ScrumMaster are certainly well founded in knowledge and experience. 

In my many years of experience with Scrum and as a ScrumMaster, I would not characterize my work as an orchestration of a team's work.  S/O, S/D teams do that for themselves.  I wouldn't even characterize myself in the ScrumMaster role as a "servant leader."  I would characterize it as a "servant."  I might lead and I might not.  That is situational.  Metaphors and analogies are helpful, but also limiting and sometimes dangerous.  They are easy to call upon and they provide familiar comfort to the mysterious. 

 

Let's see what the Scrum Guide says about ScrumMasters:  "The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.” 

 

 

The Guide then goes on to list ScrumMaster services provided to the PO:  

 

• Finding techniques for effective Product Backlog management;

 

• Helping the Scrum Team understand the need for clear and concise Product Backlog items;

 

• Understanding product planning in an empirical environment;

 

• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

 

• Understanding and practicing agility; and,

 

• Facilitating Scrum events as requested or needed.

 

And services provided to the Development Team:  

 

• Coaching the Development Team in self-organization and cross-functionality;

 

• Helping the Development Team to create high-value products;

 

• Removing impediments to the Development Team’s progress;

 

• Facilitating Scrum events as requested or needed; and,

 

• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

 

 

And services provided to the organization:  

 

• Leading and coaching the organization in its Scrum adoption;

 

• Planning Scrum implementations within the organization;

 

• Helping employees and stakeholders understand and enact Scrum and empirical product development;

 

• Causing change that increases the productivity of the Scrum Team; and,

 

• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

 

It seems clear what the ScrumMaster is to do.  How you characterize the person – a role or a title – seems trivial except to people who care about such things.  I have seen many various people serve admirably as ScrumMasters and the title or role was unimportant to them.  What is important is performing in the role with élan and bringing about expected value through such performance. 

While career ambitions are perhaps an admirable quality, they are realized because of qualities in work and performance are realized and appreciated.  Values and instincts can be acquired – through experience.  There is an old Montana cowboy wisdom about it:  “Good judgment comes from experience, and a whole bunch of that comes from bad judgment.”

 

December 24, 2013 - 1:27pm

About the author

Mariya Breyter's picture Mariya Breyter

Mariya Breyter is an IT management and project management professional with over ten-year experience ranging from government jobs to versatile corporate experience in media and education. She is a passionate agilist and an active member of New York City agile community. Mariya is also a contributor to a number of online resources on agile and project management topics, including her own blog. In 2011, Mariya was selected as one of the winners of The IT Metrics and Productivity Institute’s PMO Case Study competition. In February 2012, Mariya facilitated a discussion on executive coaching in Agile at Agile Open NYC. She has combined BA /MA degree in Linguistics and Computer Science and Ph.D. in Computer Linguistics from Moscow State University, followed by post-doctoral fellowship at Stanford University. Mariya mostly enjoys coaching teams in their  journey to a successful Agile implementation.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03