Just like the US Government has 3 branches (Judicial, Executive, and Legislative Branches), Scrum has 3 roles. Many people compare the counter-balance of each roles in Scrum to that of the US Government. It's really about the checks and balances. But I truly believe it is even more than that.
The 3 roles in Scrum are Product Owner, Scrum Master, and Development Team. Naturally the Product Owner and Scrum Master are also on the "Team", but let's look at why we have the roles. Balance of power is definitely a good reason, but the other reason that often goes overlooked is one of the actual Scrum Values of "Focus". Each role has a focus and giving that person the role allows them to "Focus" on that role and the needs of that role from the holistic team.
No doubt that the role can be a "hat" in the organization (i.e. a CEO of a small start up might actually act as its PO). The point is that the team understands who is filling the role and what those responsibilities are for the role. Let's take a look at a snapshop of what these roles do according to the Scrum Guide:
Product Owner
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Development Team
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
- Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
- Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
The Scrum Master
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.
In addition, the Scrum Guide goes on to mention that the Scrum Master performs services to the Product Owner, Development Team, and the Organization. Isn't that interesting? Scrum Master is often the role I see the most as "shared" between other members of the team (i.e. the Scrum Master is a Development Team member, or the Product Owner).
If you truly want to transform your organization and remove impediments to software delivery; at the bare minimum when starting out with Scrum, ensure these roles are dedicated to the effort. The more you dilute the role, the less you will get. That is true of any role or responsibility. Dilution is the enemy.
If your organization is just beginning on implementing Scrum or has been doing it a while, take a look at the starting gate for implementing the process. Make sure the roles are dedicated and are clearly understood by the team. Not only what the role does, but WHO is filling that role.
