Scrum Roles Demystified
Who the 3 main players are, and what they do
When an organization decides to embrace Scrum, one of the first things to understand is how Scrum roles differ from traditional project execution roles. While there are only three main roles in Scrum, they don't automatically align with titles familiar to most of us. Let's start with a brief definition of each:
Product owner – holds the vision for the product
ScrumMaster – helps the team best use Scrum to build the product
Development team – builds the product
That's fine, but for organizations that aren't familiar with Scrum, it probably doesn't help much. Further, the roles may sound close enough to traditional Waterfall-based project management to encourage comparison -- the product owner is like the sponsor, right? Well, no . . . so let's look at the roles in more detail.
The product owner: The hub of business value
The product owner is the cornerstone of project success, responsible for defining the work that needs to be completed and prioritizing that work. He or she needs to know what the project is expected to deliver and why
those elements are important -- to customers, to the market, to the organization. The product owner must also be the face of all of those interests to the project team, acting as an expert guide as the team carries out the project.
An important difference between the product owner and any nominally similar role in traditional project execution is that the product owner remains actively involved throughout. For example, the product owner reviews and reprioritizes outstanding work based on shifting needs and ongoing feedback. That contrasts with a traditional sponsor, who defines all of the work up front in the scope statement. By extension, the product owner is also responsible for communicating and explaining those changing priorities and their impacts to the project team.
The product owner is the hub of business value for Scrum initiatives; his or her entire focus is on ensuring that the work actually done aligns with the work that needs to be done to meet the project objectives. This may create the temptation for product owners to try to control the work, but that is not part of their role (we'll explore that more when we get to the development team). A product owner must be highly self-disciplined to avoid trying to manage the development team's activities. He or she is assisted in that by the ScrumMaster.
The ScrumMaster: The protector
The ScrumMaster role has two distinct elements. First, he or she acts as the protector of the team, making sure that everyone on the project, especially the development team members, can focus on their work without any distractions. Some of those distractions may be directly associated with the work -- the product owner who oversteps the boundaries, for example, and starts to dictate the work approach to the team. Or the ScrumMaster may need to protect the team from organizational disruptions or internal distractions -- arranging to replace problematic computers or providing a less noisy work area, for example.
The second element of the ScrumMaster role is to protect the Scrum process itself. The ScrumMaster is the expert on how Scrum works and how it should be applied. He or she will ensure that the product owner and development team stay within the Scrum framework. By extension, the ScrumMaster can coach the other team members on how to use Scrum in the most effective manner.
This is a very different role from that of a traditional project manager, despite frequent comparisons made between the two. Project managers are responsible for managing the work of project team members, and that guides their own day-to-day work. For the ScrumMaster, however, the only formal accountability is over the process.
The development team: The autonomous collective
This leads to an obvious question: Who does
have accountability for the people doing the work? That's where the development team comes in. A typical Scrum team consists of five to nine people and generally includes the typical functional roles required to complete the project. In software development, that means architects, testers, developers, and designers; but those titles are only relevant in establishing each individual's expertise.
The team acts collectively to determine how to achieve their goals. The specific features they work on are determined by the priority established by the product owner. The way they work is guided by the Scrum process, as monitored by the ScrumMaster. Everything else is up to the team to manage, with the ScrumMaster providing as much support as needed to allow that to happen. For example, each team member can take a feature from the prioritized product backlog, then decide individually how to execute that work.
This level of autonomy is a cornerstone of Scrum. It encourages strong bonds between team members and helps create a positive working environment. While the idea of a team exists in Waterfall projects as well, in that environment the team is functionally managed by the project manager, rather than being self-managed.
The synergy: Unique roles working collaboratively
Here we only scratch the surface of the three Scrum roles, but it's enough to establish that each is unique to Scrum -- these aren't simply revised Waterfall roles. Further, each one complements the other; success can come only from embracing all three and allowing them to work together. As organizations move toward Scrum, it is vital that they support each of these roles, allowing time for expertise to develop and resisting comparisons between Scrum and Waterfall.