Scrum has only three official roles: Scrum Master, product owner, and team member. No distinction is made for roles like programmer, tester, database engineer, analyst, designer, or so on.
A tester is, for example, a team member. The tester has the same responsibilities as every other team member: produce a potentially release product increment by the end of the sprint that achieves the sprint goal.
How each team member helps the team accomplish this goal will differ. A tester will, whenever possible, select testing work from the sprint backlog. A designer will select design work.
But everyone on a good Scrum team is expected to help out any way they can.
Specialist Roles on Scrum
In contrast to the role of team member are the roles of product owner and Scrum Master. These roles can be thought of as specialists.
Neither the product owner nor the Scrum Master has a responsibility to directly aid in creating a potentially releasable product increment during the sprint. On many teams, they can help but it isn’t required as part of Scrum.
Why Are These Roles Unique?
What is so unique about the product owner and Scrum Master roles that each is a distinct role, unlike tester, programmer and so on?
Many teams already experiment with rotating Scrum Master duties among multiple team members. Others treat it as an additional set of responsibilities taken on by a team member.
Yet the vast majority of Scrum teams still have a separate product owner role filled by a dedicated person representing the interests of the organization or its stakeholders.
An Intriguing and Appealing Future
I think an intriguing and appealing future is presented by the idea that the product owner role could go away. Current product owner responsibilities would become shared across the entire team, much as testing responsibilities are shared today.
I do not believe there is anything inherent in the product owner role that prevents it being shared.
Just as testing on a good agile team today is a responsibility shared by the entire team so too would product decisions be shared.
Teams are expected to self organize and determine for themselves the right answer when faced with architectural choices. The same could be expected of product decisions.
When faced with a decision that would have previously been made by their product owner, team members instead talk about it and decide collaboratively.
This really is no different than team members making architectural decisions.
Rather than having a dedicated product owner, a team might have a team member with more expertise making product-level decision. But this is no different than having a team member with more experience testing who prefers to test but who will do anything.
What’s Necessary for This to Work?
A few things are necessary for this to work. First, developers need to move beyond thinking of themselves as code monkeys. They cannot just show up at work and announce, “I’ll code whatever you want, but tell me exactly what it is.” For a Scrum development team to participate at this level, team members need to bring their whole heart and passion.
Second, product owners will need to let go of the idea that product-level decisions are solely theirs to make. A tester on a Scrum team may prefer testing over all other activities. But that doesn’t mean testers get to make all testing decisions on their own.
These changes mean the entire team will be responsible for achieving whatever big goal it is assigned. Thinking that leads to referring to the product owner as “the single wringable neck” will go out the window.
So Who Is on the Team?
In what I’m describing and in what I’ve encountered already in a very small number of organizations, teams would exist as today with one exception. Rather than a dedicated product owner who is often thought of as separate from the team (and is defined as such by the Scrum Guide), product ownership duties would be performed collaboratively by the team.
Organizations would very likely assign someone with product management experience to the team. This would be no different than how someone with testing experience is assigned to the team today.
This person would be expected to lead or guide many product management decisions. But the person would rely on selling teammates on the benefit of a decision rather than telling them a decision.
A Natural Progression
I am opposed to anything that creates an us/them divide within a team. I’ve written previously about the importance of including product owners in daily scrums and retrospectives and I’ve written about including team members in creating the product backlog.
As teams more fully embrace whole-team thinking, differences among roles will be seen as more artificial even as individuals in those roles do more highly specialized work.
I believe we are already seeing this in how organizations view Scrum Masters. In coming years it will be a natural progression for this whole team thinking to extend to product owners.
Teams will have some stakeholder or business representative on the team, but that person will not be solely responsible for product decisions as is commonly the case today. Rather, teams will make those decisions entirely collaboratively and with shared responsibility.
