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.
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.