Mixing Roles in a Scrum Team

Mixing Roles in a Scrum Team

mix of colorful candy

One of the powerful advantages of Scrum is having two different types of responsibilities: the shared responsibility for the final product, and the individual responsibility based on each team member’s role.

Responsibility for the product is shared by the whole team: the product owner, scrum master and development team are all collectively responsible for the development and delivery of a working product at the end of each sprint. On the other hand, each one of those team members is also individually responsible for a specific part of the product.

While the product owner is responsible for gathering requirements, shaping the product vision and prioritizing the “What, Why and When,” the development team is responsible for devising ways to  provide the needed features, as well as determining how much time and effort is needed to fulfill the requirements of each user story.

The Scrum Master, by supporting the team and driving them to achieve better results, acts as the catalyst of the sprint.

Despite this separation of roles in a Scrum team, sometimes management thinks that it makes sense for a single team member to take on multiple roles.

I’ve heard about teams where a developer acts as Scrum Master, as well as teams where the Scrum Master role is rotated among the development team members. My view on this approach is that it creates an unhealthy structure due to the conflicts of interests present within each role.

I would find it strange for a developer who is supposed to work on user stories provided by the product owner to simultaneously coach the product owner on how to write and prioritize user stories.

This type of team structure also fails to deepen the development team’s confidence or trust in the product owner to decide what features are needed or make proper decisions.

One other unhealthy situation occurs when the line manager of the team was also a developer who was actively participating in the development. The lack of a boundary between these roles can cause various different problems.

The development team wouldn’t be eager to challenge their “colleague’s” technical proposals, since he or she  is a member of the same team. Sometimes the developer-manager would overrule the product owner, since he or she was the product owner’s manager as well. 

In some situations, user stories might get injected as a result of urgent requirements from management. For example, a user story to show a report needed by the management might get injected in a sprint hindering the delivery of another user story needed by the customers.

A different type of structure, which can be frequently found in startups, involves a developer who is also the product owner. This structure would succeed only if the developer managed to overrule their inner geek in favor of the business needs of the product.

When the founder is not able to differentiate between his or her role as a developer and his or her role as a product owner, the success of the startup can be jeopardized. The few startups that do succeed are able to do so because of this key factor.

In normal cases, I would prefer that the roles in a Scrum team remain separated, as they should be, in order to enable each team member to achieve what is expected from his or her particular role.

Effectively creating a healthy environment in which a team can work properly is critical to the team’s success, and thus should be a top priority for management.

Have you ever worked in a team with mixed roles? I would like to hear about your experiences and thoughts in the comments section below.


Islam Kotb Ismail (PMP, CSM, CSPO) is a senior agile project manager and Scrum Master at Wirecard Technologies GmbH in Munich, Germany.

Learn More
comments powered by Disqus