Get certified - Transform your world of work today


A Scrum Master Is Not a Project Manager by Another Name

16 August 2012

Steve Hunton
Scott Logic

Contrary to popular belief, the ScrumMaster and project manager roles are highly different and shouldn't be confused. As more companies migrate their project management to Agile, many do so without a proper understanding of what they're aiming for. In particular, there are incorrect assumptions made about the roles in Agile; people often expect that the shift from Waterfall practices includes a wholesale shift of roles. The ScrumMaster, however, does not play the part of the traditional project manager. In fact, the ScrumMaster is an entirely new role. (If you're looking for the project manager within Agile, you'd be better off looking to the product owner.)


Who does what?

Traditionally, the project manager is a leader, a decision maker, a planner, someone who manages the project and the team and is the person accountable to the business for accomplishing the project objectives. The ScrumMaster's role is more that of coach and facilitator, a role that sits between the project and the customer. The ScrumMaster doesn't manage the team that produces the work; instead, he supports the product owner, coaches the team, and makes sure that Scrum processes are adhered to. The ScrumMaster is responsible for the Scrum process, its correct and continuous implementation, and the maximization of its benefits.

Product owners have a huge responsibility for the project — their project. They're responsible for maintaining a product backlog that describes the product and continues to fit with the requirements of the business. During any project, as more becomes known about a product, about customers, or about changes in the market, a product may need to change in order to meet these requirements. The product owner has to adjust and reprioritize the backlog to fit these changes and steer the project. With many projects, that's a big task, one that many product owners struggle with — and occasionally avoid.

The ScrumMaster is there to help, coach, provide a consultancy role, and look at the project from all angles. The project remains the responsibility of the product owner, and it's up to him or her to make the final decisions. However, the product owner can look to the ScrumMaster to help answer questions about user experience, functionality issues, user feedback, and any need to realign the development to fit with changes outside the business. The ScrumMaster helps the product owner understand how to effectively manage the work of the team, using the product backlog and the planning and review meetings.

ScrumMasters can come from project management, but that's not a guaranteed fit. Business analysts and team members can also fit the role. A lot of traditional project managers (PMs) struggle with the transition because it means stepping away from a highly structured position: one with them at the helm, steering the development and the team toward a predefined specification. The often overwhelming change controls imposed in traditional Waterfall approaches are no longer there to protect the PM from the risks associated with change. Gone is the overanalyzing, form-filling approach to change. The product owner often now has to deal with change on a daily basis. Those changes aren't always big shifts, but the decisions made to include them can have a big effect on the end product. Being able to make those decisions is important to the flow of the project, and a product definition may change massively from what it looked like at the beginning. In fact, a product doesn't even need to be fully defined at the outset of an Agile project. That scares the pants off many traditionalists!


The coach, mentor, and Scrum guardian

This is where the ScrumMaster plays a vital role. While Agile is becoming a part of many projects, there are still those who shy away from it, are nervous about it, or just don't trust it. They find the traditional PM role far easier to understand. What they don't realize are the restrictions imposed by the old role and approach. The ScrumMaster has to coach the product owner to understand how to achieve the goals and how to continually adapt and prioritize the backlog. The ScrumMaster is the link between the product owner and the team.

The team, depending on its level of experience, may also look for guidance and help in solving issues and blockers. The ScrumMaster needs to steer the development through these issues, resolve any problems that are blocking the development, and involve those with the needed skills and experience. There is often a lot of noise from within the business, and it's down to the product owner and the ScrumMaster to protect the team from that noise. Changes in what is being developed should be communicated via the product owner and nobody else.

As a project progresses, the product evolves. What might have been expected at the start of the project is not necessarily what we produce. User feedback, for many products, is essential for defining a good, solid, usable product. Organizing product reviews and dealing with feedback from users is imperative for the success of a project and the product it's producing. It's really not enough to produce a product that the client thought was needed. In order for a product to work, there has to be feedback from a wider audience. Its experiences and feedback need to be managed through the product backlog (provided the product owner considers them suitable for the product). Again, the ScrumMaster can help facilitate these changes by helping the product owner describe them, understand their impact on the product, communicate them to the team, and prioritize them in the backlog.


The ScrumMaster is not a lead developer

The team tasked with developing the product has a huge responsibility. It's required to understand the requirements, break them down, and then accurately estimate, produce, and finally demonstrate the output. The ScrumMaster needs to help the team by facilitating the reviews and planning sessions, but he or she isn't there to manage. The team is responsible for managing itself. In most teams there is a lead, generally the most experienced member, who steers the team, reviews proposed solutions, and makes decisions. The ScrumMaster is there to support the team and provide input and support when required.

There are teams, particularly in software development, who find it difficult to differentiate between the ScrumMaster and the lead developer. Often a the team needs a development lead who has particular skills and experience and is able to manage the team and make its decisions. This is not a ScrumMaster role; it is specifically a role required within the team. It's up to the team to lead itself, either with a lead role or a collective togetherness.

This leads some to think that the ScrumMaster role is not required — but that's not the case. The roles are entirely different. The ScrumMaster is there to facilitate, coach, and provide support. If the project requires someone within the team who can manage, lead, and take responsibility for the development, then that needs to be defined by the project. That lead role should be allowed to concentrate on the development and produce a product to the best of the team's ability. The lead should not be distracted by the wider project or the broader considerations of the organization.


ScrumMaster summary

So remember: The ScrumMaster is likely to be someone you've not met before if you're from a more traditional background. He or she is a facilitator and a coach but isn't responsible for the project or managing the development team. If you have questions about the product being developed or you want to contribute to the product, then the product owner is the one whom you need to look for. If the ScrumMaster is making decisions about a product, then Scrum has not been properly implemented and there's going to be confusion and conflict about who does and owns what.

There you have it: The ScrumMaster is an entirely different role from that of the project manager or the lead developer. You can be a ScrumMaster and a project manager — but only on separate projects.

An Agile project is defined by the product owner and developed by the team. The ScrumMaster is there to facilitate, make sure that Agile processes are being followed, and support the product owner and the team.

It sounds like a cushy job, but it requires particular skills and experience, and it takes the right person to make it work.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.8 (25 ratings)


Jocelyn Walker, CSM, 8/16/2012 7:50:25 AM
thanks for this Steve, really useful and thought provoking article
Sebastian Dieguez, CSD,CSM, 8/16/2012 9:10:55 AM
While I agree in ALL of the points, sometimes my take away from articles is "the SM is this or that" without giving much in-depth of the foundations on why is that way. Will research some psychology stuff on that.
Don Kim, CSM, 8/16/2012 9:35:07 AM
While I agree for the most part with the outline of the ScrumMaster in this article, the section where you state "the product owner has to adjust and reprioritize the backlog to fit these changes and steer the project", I think this should fall under the ScrumMaster in that s/he facilitates the ordering and re-ordering of the backlog between the PO and the team.
Steve Hunton, CSM, 8/16/2012 6:48:03 PM
Hello Don and thanks for your response.

The Scrum Master isn't responsible for the backlog, that is the responsibility of the Product Owner. The role of the Scrum Master is to coach and help the PO understand their role (many still don't understand it) and to help them define a backlog that meets the requirements and priorities of their business. Often the PO needs some help prioritising so I get them to look not only at the stories but at the value. For example, comparing the perceived business value against the effort will give a good indication of the ROI. In many cases the PO can get hung up on a user story that's important to them but when they see the amount of effort estimated then the ROI helps them to assess business priorities in a different way.

This is just another example of the Scrum Master playing a very different role to that of the Project Manager who would traditionally define the priorities of the project themselves.

Juan Banda, CST,CSP,CSD,CSM,CSPO,REP, 8/17/2012 11:29:25 AM
Nice article Steve.

I have one comment about this paragraph "The ScrumMaster is there to help, coach, provide a consultancy role, and look at the project from all angles." Those other angles that you mention perhaps are referring to coaching, team cultivation and transforming team member's mindset to Scrum; I'm not seeing for instance the SM dealing with aspect like procurement, performance evaluations and other important areas in a project.

Interestingly enough the PO is owning the project but from the perspective of delivering highly valuable features for the customer and not from a global perspective like a PM does.
Carlos Eduardo dos Santos Nunes, CSM, 8/18/2012 4:25:04 PM
Very nice article! You help me to look out of the box! Recently, I have faced some difficult because, as a Scrum Master, I made some thing as a project manager, and this role, belongs to the Product Owner. I am a entusiastic about Agile and best practices of the PMBOK too, so the last side belongs to the PO not Scrum Master. Thans for your help Steve!
Soumya Sikder, CSM, 8/20/2012 4:57:39 AM
Very good article indeed! actually the role of SM is quite explicit and need proper understanding. Well I agree to ALL of the above points, but in addition to this I am interested to know "How to evaluate a SM?". I myself being a SM need to know if my role is only confined to coaching, facilitating and ensuring Team's productivity only. From the Organization perspective in general what other aspects can a SM contribute?
Steve Hunton, CSM, 8/20/2012 8:24:59 AM
Soumya, that all depends on what you're SM'ing. Within my company we're very focussed on quality within the projects so that means I have to ensure that the quality system is being adhered to. Because of the company setup I see this as part of my SM within the organisation. Throughout the project I need to ensure that things are recorded in order that estimation, customer satisfaction and our own evaluation of the project can be measured. Our measures and feedback are used within a continuous improvement cycle. Because this ultimately affects the customer the SM needs to coach the team and the PO in order to understand and appreciate the importance of it.

The SM also needs to keep the PO focussed. Whether the PO is familiar with the role or not there is a lot for them to deal with and it's easy for them to take their eye off the project objectives and what it is that they're trying to achieve. By maintaining your own focus on the client's objectives you can coach them towards a product that they need, to help them understand what's important, to order and prioritise and to take their focus away from those little bits of *glitter* that clients often get hung up on, the glitter that's unimportant within the bigger picture.

There's also the needs of the team. Just dealing with blockers can be a big task in itself. You often get sucked into politics when dealing with the bigger organisations but it's part of your job to shield the team from those politics and deliver solutions to their blockers.

Don't underestimate the size of the SM's job or the enormity of the responsibility. Effective and suitable products are difficult to deliver, particularly when we start to introduce change and complexity. The end goal often changes throughout the project and it's your job to help keep the project on the best and most suitable course for success.
Don Kim, CSM, 8/22/2012 2:29:46 PM
Hi Steve, I think we're pretty much saying the same thing but with you leaning more toward this being a clear role and responsibility of the PO whereas I lean more toward the SM. That is why I used the term "facilitating" rather than directing of the PO to gather the backlog requirements. The reality is that every PO will have differing knowledge, ability, temperance and expectations with regard to what they're suppose to be doing. Due to this a skilled SM will have to determine whether s/he has to educate, coach and nudge a PO to do the right thing or if s/he can allow the PO to self-direct. If no action or the least effective action is taken, this will become a rather critical impediment.

I completely agree with you that the SM role is very different than the traditional PM role, in that it requires more emotional intelligence, subtle leadership, diplomatic gracefulness all the while having the ability to "nudge" hard if needed, or lay back and allow teams, PO and customers to self-direct.

One thing we have to be careful of is hard coding roles and responsibilities to the SM, PO and team, because to do so falls prey to the idea that all these things are pre-determined and steadfast. Scrum was inspired by the HBR article written by two Japanese professors who come from a culture of Eastern thinking which unlike the West, embraces paradoxical thinking. Therefore, it should not be surprising if roles intermingle with SM's taking on PO roles and visa versa, or teams crossing over functions. This should not be discouraged, but rather embraced since to do so is to practice Scrum to it's fullest.
Valerie Santillo, CSM, 8/22/2012 5:16:52 PM
Great article! I started out as a PM and the mind shift that's necessary to be a SM is challenging to say the least. The challenge is amplified when an organization is transitioning to Agile from waterfall and looking for the SM to be a PM. Additionally, the results you achieve as a an SM are very different than those of a PM and, for some, it may not be as rewarding. All of that said, teams are unique and the SM needs to be able to adapt to what the team requires - even if that means expanding the definition of SM...for a little while.
Embrenchia Snyman, CSM,CSPO, 9/27/2012 3:29:11 AM
I like it! I love it! I feel sane again. Have always had these views, you've worded it beautifully.
I think many companies are reluctant to face the fact that project managers do not have a role in Scrum and would rather "double-up" their PMs into SMs, rather than developing them into POs, or letting them go. #noelephantintheroom
Carlton Nettleton, CST,Educator,CSP,CSM,CSPO,REP, 11/14/2012 8:04:57 PM
Very interesting distinctions you make regarding the role of SM
Bill Rinko-Gay, CSM, 12/24/2012 1:32:19 PM
I thoroughly agree that a Scrum Master is not a project manager. I think you've downplayed the enabling role of Scrum Master within the Team. I agree The Product Owner owns the product and, therefore, the backlog. I agree the Team owns developing the product. The Scrum Master is left with the tasks of enabling the Product Owner and the Team. This includes the coaching items you mentioned, but it also includes handling the logistics of the team, interfacing with external groups to remove roadblocks, and buffering the team from distractions like communicating status or responding to management requests. The description I like best is "servant leader."
Jim Rice, CSM, 2/4/2013 9:39:51 AM
@Steve, Welcomed article and content. There is so much contraversy and confusion out there about the PM versus the SM, including about and among the FM(Functional Manager)or RM (Resource Manager). Having appropriately supportive responsibilities and relationships between these leader roles (particularly the PM and SM) is crucial in an agile setting. @Juan, valued comments. On the mark.
@Bill, you got it. Role of SM is [often] underplayed and undervalued. Servant Leadership is the pinnacle of the agile paradigm. And it's certainly not new. In fact it's thousands of years old. We just have such a difficult time as people understanding that the command and control paradigm, while it has it's place and purpose in humanity, simply and consistently fails to foster high-quality, high-value innovation and creativity. As Bonnie Raitt puts it, "I can't make you love me, if you don't." :)
Eduardo Roberto Silveira, CSM, 8/13/2013 6:19:26 AM
Hi, very nice article. Now i realize that SM is involved with the project.
The SM commitment's is the process.
Pradeep Kulkarni, CSM, 1/14/2015 10:38:38 PM
Really Nice article, it gives clear understanding. Thanks much.
Tim Field, CSM, 4/24/2015 10:35:08 AM
This is my take on it (slightly different perspective). I hope this adds to the debate!
Chia-Shen Chuang, CSM, 6/24/2015 3:01:30 AM
Really nice article! Thank you Steve!
Hiren Pandya, CSM, 12/23/2016 7:01:27 AM
Very Nice article Steve. I was looking at something to relate to on this topic. Even though it's an old article but its relevant even today.
I was looking at more detailed description so could you please delineate the PM role Vs the Scrum Master role, especially for those projects which are transitioning to Scrum from traditional model ?

Thanks for such a wonderful article !
Tony Bresse, CSM, 12/28/2016 6:10:04 PM
Hi Steve,

Great article, thank you for sharing.

One thing you have mentioned is that "You can be a ScrumMaster and a project manager but only on separate projects."

There was one project that I was both the PM & Scrum Master,
where as PM I had to produce timeline planning for Sprints Iterations, defining risks,
communicate projects status to executive, and work closely with product owners.

While at the same time I was playing the role of Scrum Master in leading and coaching the Scrum team
and work closely with product owners.
Christopher Davey, CSM, 5/24/2017 3:50:04 AM
Hi Steve,

Nice article and certainly a message that needs to be shared as it doesn't seem to have reached a lot of organisations.

From experience I would suggest that a team need to be careful about lead developers and potentially one being present can lead to less team empowerment and less innovation from the team. If there is a lead developer the SM will need to carefully coach them to ensure that they don't become the new command and control point or single point of failure. Make sure they don't lead conversations and that all ideas are heard. Usually this is fairly easy to spot but with remote teams this can be a real challenge.

In Scrum all members of the development team are created equals.
Tammina Raghu Ramudu, CSM, 6/13/2017 7:19:30 AM
Thank you for the nice article Steve. It gives the clear difference.
Atish Jadhav, CSM, 9/1/2017 8:14:08 AM
Nice article!

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up