Combining Roles in Scrum: Pros and Cons!

In this article, I will try to mention the pros and cons of combining roles in Scrum referring to useful hints from the books and to leverage my professional experience.

I will try in to leverage my professional experience and also taking advantages from some useful hints from “The Great ScrumMasters” book written by “Zuzana Sochova” (I highly recommend the book ) to mention the pros and cons of combining roles in Scrum.

So let’s just dive in …

The scrum guide defines the roles and their goals in scrum.

Scrum Roles at a glance (from scrum guide 2017)

Development team:

The Development Team (typically between 3 and 9 people, not including the Product Owner and Scrum Master) consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

Development Teams are structured and empowered by the organization to organize and manage their own work (self-organizing team). The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness

Product owner:

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.

The Product Owner is the sole person responsible for managing the Product Backlog.

They are the voice of the client, the representation of the product stakeholders and he is the responsible for the delivery.

He is responsible for prioritizing the backlog and he is the decision maker regarding what features the product will have. That means, the PO should understand the market, the customer and the business in order to make decisions.

Scrum master:

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master is a servant-leader for the Scrum Team.

The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Combining roles in Scrum

Referring to my experience as a scrum master and also as a proxy product owner, I discovered that combining roles in Scrum is very difficult and can be frustrating to all the team, hence affecting products.

I will just start with a small statement: A Scrum team member who combine roles must be good at distinguishing between one from the other. He should wear only one hat at a time.

But I suggest always separating them, especially for team just starting using Scrum and Agile practices, otherwise all roles will suffer.

I will try to provide some examples of roles combinations in Scrum and mention the pros, cons and result for each one.

The Scrum master as a Team Manager

Cons: The SM might be directive, relying on controlling and micromanagement instead of coaching and mentoring. It will be difficult to him to establish a full trust with the team.

Pros: Good Managers are leaders and have experience with change management, so they catch on more quickly in the transformation period.

Result: The roles of the scrum master will not be giving the attention it requires, with the right conditions and cultures (not on the directive once) this is could be an opportunity to start the agile transformation.

However the dream job of the team manager is not to become a Scrum master but to lead organization, so they can fulfill the SM role only temporarily.

Despite the possible positive impact, teams where the Scrum master is a manager often lack self-organization, self-confidence, and ownership, as the manager, not the team, decides, manage, fixes and arranges.

The Scrum master as P.O

Cons: There might be a conflict of interest as the scrum master and the P.O roles have different goals.

The SM should never be responsible for delivery that is the Product owner’s main goal.

The conflict would be between business needs and team self-awareness. because it is difficult to balance long-term versus short term improvements and results.

Pros: A P.O who is also a Scrum master is more likely to be treated as part of the team.

Result: In most case the role of the scrum master is neglected and the P.O controls everything.

The team will lack self-organization and deep understanding of Scrum and Agile practices.

The Scrum master as a Team member

Cons: the Scrum master is too much engaged as a team member, so that he lacks system view and system thinking ability. He often neglects leadership and change management skills.

Because he diving on the technical aspect “The how”, he is less able to improve the team and unable to move with the team to the next level.

Pros: The SM is a part of the team and there will be a mutual trust with team members.

The scrum master will have a good understanding of the team weaknesses and can easily point them out at a retrospective.

Result: The SM role could be interpreted less important and often disappears. The SM could be reduced to the level of the team assistant.

The scrum master will take care of facilitating meetings, management of such scrum tools like JIRA or Confluence and assist the team on such simple tasks. The role of the SM will not give to the team and the organization what is actually expected. As a result will not improve significantly.

The P.O as a Team member

This is could be a source of conflict of interest. The P.O wants a delivery as quick as possible while the team member focus more on the product quality.

Pros:

The P.O will have a better overview about the quality of the product development and he will detect quickly the misunderstanding of the requirements inside the team.

Cons:

It will affect the P.O’s way of prioritizing the requirements because it will have him think about both the customer value and technical aspect.

Feedbacks during the sprint review will be influenced by the technical aspects, thus you can miss easily the user perspective.

As a P.O while focusing on the technical side you will miss the clear vision of what the user need because most of the time is spent on the development.

Spending most of the time as a P.O, your team will suffer finding the good design and technical solutions especially????? . Your output as a technical lead will drop down.

Result: If your time will be divided into these 2 roles, both roles will suffer and at the end your product quality will be affected.

The P.O focus on the “WHAT” and the team members on the “How”.

The scrum master as a servant leader

The scrum master is a leadership role. One of the goals of the scrum master is to make others work better; unleash the team performance by focusing on the scrum teams as well as the overall organization.

The SM is not only someone who understands Scrum; he is much more than that. He cares more about long-term goals and strategy more than the short-term metrics.

Leaders are not driven by time sheets, instead they have a clear vision, are self-driven and creative.

The philosophy of the scrum master is to “putting your team first, and yourself second”.

The scrum master should improve his skills to fill his responsibility, he should be able to listen to others, be self-aware as a leader, working on healing relationships and he should be committed to the growth of others.

To summarize, we should remember that:

1- The SM has a leadership role; it requires creativity, vision and intuition to succeed.

2- Good scrum master are empathetic, good listeners, and ready to heal relationships.

3- Great Scrum master are not solely focused on their teams but are able to build communities across the organization.

Conclusion:

It’s good for the P.O to have knowledge about agile frameworks, practices and also a good technical background. These skills should not influence the team especially in the technical side.

It’s good for the Scrum master to have a solid background on business to coach the P.O and technical background to support the team detecting impediments and remove them.

It’s good for the team members to know about the business side which will be helpful to have a good customer value thinking.

It is important also to understand the values behind Agile practices so they improve the way of working.

I think these roles are complementary, they are a full time jobs and it’s highly recommended to separate them in order to get the best value out of them.

And you, what is your experience about combining roles in Scrum? What do you think about separating them?

I look forward to your comments.
If you found this post helpful follow me on medium and Linkedin

Thanks for reading …