Scrum Roles Defined
I do a lot of work with Scrum Teams and the ones that struggle the most are the ones where the Scrum roles are defined poorly and\or not filled properly. Scrum is a balanced framework and when the roles get muddled, the framework begins to adopt the dysfunctions of the organization and is not as powerful as it could be.
In Scrum there are three roles – Team member, Product Owner and ScrumMaster. Those three working together are called the Scrum Team (or just the Team). I add a fourth role – Stakeholder – to recognize all the people who orbit a Scrum Team and influence them. I define all these roles like this:
- Team: dedicated collection of self-organizing, interdependent, co-located individuals representing different functional roles with all the necessary skills to turn Product Backlog items into a potentially shippable increment within the Sprint.
- Product Owner: an empowered individual applying their personal and professional judgment to make decisions in the best interest of different,often times competing, business stakeholders to maximize the business value the Team produces each Sprint
- ScrumMaster: a dedicated individual responsible for improving the performance of the Team and the business by any means necessary.
- Stakeholder: any person who has a direct, or indirect, interest in the work of the Team.
Keep in mind, these are role definition, not job descriptions and they are very loosely defined. It is important that each role is filled. In general, the Product Owner is concentrated on the providing valuable business outcomes to the business, while ScrumMaster is aiming his\her efforts at the execution of good Scrum and improving the flow of value to the customer. Meanwhile, the Team remains centered on learning how to self-organize and deliver potentially shippable increments regularly. Stakeholders provide feedback on the value of everyone’s efforts.
When Scrum falters, it is often because people are not committing to their roles. Other times, organizations chose to overload one, or more, roles in a single person, disrupting the balance of the roles. Recall, the Scrum framework was designed to provide the maximum amount of flexibility with the minimum amount of control. If these roles cannot be filled with individuals who will fully inhabit them, or they are overload, the control mechanisms of Scrum become unhinged, visibility is diminished, accountability is lost and the framework loses its meaning.
When Scrum is done well, there exists a natural tension between each role. This tension exerts a force that tends to prevent the other roles from meddling in responsibilities that are not their own. Since there are considerable gray areas on the role boundaries in Scrum, each role will eventually bump into one another as they discover what are the boundaries of their responsibilities. This friction is an essential part of learning how to do Scrum and making it meaningful to your business. Through the of process of inspect-and-adapt, the precise definition of each role – Team member, Product Owner, ScrumMaster and stakeholder – emerges as your organization gains experience using Scrum.
One of the main reasons why I add a Stakeholder role to Scrum is because many Scrum implementations improperly keep these people out of the process. Scrum was not designed to keep the Stakeholders from interacting with the Team. In fact, Scrum was designed to bring these folks closer together. What Scrum tries to do is give the Stakeholders a more meaningful, structured way to interact and provide the Team with feedback via the Sprint Review. This is the opportunity for the Team to hear direct, unvarnished feedback on what they really think. This is why Stakeholders have a dashed line connecting themselves with the Team, rather than a solid line.
