Shared Roles in Scrum Teams: Real-Life Challenges and What Works

In this section, we will look focus on Shared Roles in Scrum Teams: Real-Life Challenges and What Works. We will explore how the value delivery gets impacted when one person takes on more than one Scrum Role within a Scrum Team. This article is part of an ongoing series on real-life scenarios that many Scrum Teams face.

“We are a small team, so one person needs to take up multiple roles. We do not have a budget for a dedicated Scrum Master (or a dedicated Product Owner)”

This is one of the most common statements I hear. Especially when organizations start their Agile journey. On the surface, it does sound practical. Why not optimise for efficiency? Why not reduce overhead? After all, if someone has the bandwidth, why not let them wear multiple hats?

However, in reality, role sharing in Scrum often creates more challenges than it solves. The issue is not a matter of capability—it is a conflict of accountability.

How do the three Roles (or Accountabilities as stated in the Scrum Guide) Interact

The people in the boat in the above diagram represent a Scrum Team. The rowers symbolize the developers. They work in sync to move the product forward through their collective effort.

The Product Owner stands at the back with the rudder, setting direction and ensuring the team is heading toward the right outcomes. His focus is always on the Value

At the front, the drummer, represents the Scrum Master. He is maintaining rhythm and helping the team stay aligned and effective. He is the facilitator who helps the Scrum Team become more effective

Success for the Scrum Team depends on coordination among the three roles. Success comes when direction, facilitation, and execution come together, the team moves faster and with greater purpose.

Below, I have described some common questions around role sharing—and what typically unfolds.

1. Can the Scrum Master and Product Owner Be the Same Person?

In one organization, I worked with a team where the same individual was acting as both Scrum Master and Product Owner. Initially, it seemed efficient—one person managing both delivery and process.

However, during Sprint Planning, this person consistently pushed the team to take on more work. In Retrospectives, when the team raised concerns about overload, the same person facilitated the discussion.

Over time, the team stopped speaking openly.

Snehamayee’s perspective

While the Scrum Guide does not explicitly forbid this, in practice, this combination rarely works well. The accountabilities of a Scrum Master and a Product Owner are fundamentally different. The Scrum Guide says that

• The Product Owner is accountable for maximizing product value
• The Scrum Master is accountable to help the Scrum Team become more effective

When the same person plays both roles, they need to balance conflicting priorities.

Impact:

• Reduced transparency
• Limited psychological safety – Product Owner is the Value Mximizer. In that role the often
• biased decision-making.

What can be done?
Keep these roles separate. Even in smaller setups, this separation creates balance and enables better team dynamics.

2. Can the Scrum Master Also Act as a Developer?

In another team, the Scrum Master was also a senior developer. During the Sprint, he was deeply involved in coding critical features.

When impediments arose, they often remained unresolved for days—not because they were complex, but because the Scrum Master was busy with delivery work.

Daily Scrums became quick updates rather than meaningful conversations.

Snehamayee’s perspective
This setup is more workable than combining Scrum Master and Product Owner roles, but it still creates tension.

The Scrum Master role requires availability and focus. When combined with development work, facilitation and coaching often take a back seat.

Impact:

• Delayed impediment resolution
• Reduced focus on team improvement
• Scrum events becoming less effective

What we can do?
This model can work temporarily, especially in smaller teams. However, it requires conscious effort to ensure that Scrum responsibilities are not neglected.

3. Can the Product Owner Also Act as a Developer?

I once worked with a technically strong Product Owner who also contributed to development. Initially, this helped speed up delivery.

However, over time, a pattern emerged. Backlog refinement became less structured, stakeholder conversations were delayed, and priorities were not always clear.

The Product Owner was simply too busy writing code to focus on product direction.

Snehamayee’s perspective
While this setup may seem efficient, it often impacts the quality of product ownership.

The Product Owner’s role requires continuous engagement with stakeholders, clarity on priorities, and proactive backlog management.

Impact:

• Backlog items lack clarity
• Stakeholder alignment weakens
• Product decisions get delayed

What can be done?
A Product Owner with technical skills can support the team when needed, but their primary focus should remain on product value and direction.

4. One Person Supporting Multiple Teams as a Scrum Master or a Product owner

In a scaled setup, I worked with a Product Owner who managed the backlog for three teams working on the same product. Initially, there were concerns about bandwidth.

However, over time, this setup created better alignment across teams. Priorities were clearer, and duplication of work reduced.

Similarly, a Scrum Master supporting two teams helped bring consistency in practices and improved cross-team collaboration.

Snehamayee’s perspective
This approach is often more effective than combining roles within a team.

When one Product Owner supports multiple teams, it strengthens product-level thinking. A Scrum Master across teams can identify systemic issues and address them more effectively.

Impact:

• Improved alignment across teams
• Consistent prioritization
• Better coordination

Some Points to keep in mind

• Beware of a too busy Scrum Master (or Product Owner). If we ask one person to be the Scrum Master (or the Product Owner) for too many teams, they become mere coordinators. It limits the value they add and the bandwidth they have for team members.
• Position an Experienced Person with proven credentials, Scrum Master and Product Owner, both are senior leadership roles – People take time to grow in these roles. If we ask someone inexperienced to function as a Scrum Master (Or a Product Owner) of multiple teams, we risk the role getting diluted
• Empower and Cross Train The Developers

Final Thoughts about  Shared Roles Among Strum Teams

Role sharing in Scrum is often driven by practical constraints. While some combinations may work temporarily, others introduce deeper challenges that impact team effectiveness.

From my experience, a few principles stand out:

• Avoid combining Scrum Master and Product Owner roles
• Be cautious when mixing Scrum roles with delivery responsibilities
• Prefer sharing roles across teams rather than combining them within a team

Ultimately, it is not about rigidly following rules, but about ensuring that each accountability is fulfilled effectively.

When roles are clear, teams collaborate better, decisions are more balanced, and delivery becomes more predictable.

The post Shared Roles in Scrum Teams: Real-Life Challenges and What Works appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do the Scrum Masters feel that they have to always protect the team?

• The earlier version of the Scrum Guide mentioned the following statement 

“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”. 

This was interpreted by most Scrum Masters that they always shield the team from the outside world.

• What ended up happening was that the Scrum Master became a liaison between the organization and the team. This way the Scrum Master became over-protective of the team and literally assumed the role of a “Dad” or a “Mom” for the team.

Some common observations when Scrum Master becomes overprotective

• Scrum Master deals with all impediments personally, even when the team members may be able to solve themselves
• Scrum Master filters feedback from stakeholders. Negative feedback is often not shared with the team. Only the goody-goody ones is shared with the team
• Scrum Master pampers the team by taking care of all administrative stuff (more like a PMO or a secretary)
• Scrum Master always becomes a bad-cop when it comes to harsh discussions with any stakeholder
• Scrum Master prevents the team from failing
• Scrum mom is not really challenging the team
• Scrum Master does not enforce boundaries and often remains too flexible with the boundaries
• “Right or wrong – its my team” behaviour starts getting seen

Negative consequences and what could be done

• Failure is not the opposite of success. Failure is in-fact a necessary stepping stone towards success. Like parents train their kids by letting go sometimes. Parents prepare the child for the real world by helping the child take up challenges. Scrum Master should allow the team to make mistakes and let go. There is no need to be over-protective. Let the team learn by failing. Scrum Master’s job is to keep showing the mirrors when failures happen.
• A Scrum Master’s good intentions can become an impediment for the Scrum team’s progress. This is particularly true in the case of an over-protective Scrum Master, when her shielding of the team prevents its members from learning by failing.
• Scrum Master’s job is to make the team independent and ready to face the world and not make them crippled by handling everything
• The greatest success of the Scrum Master is to see his/her team becoming Self Managed not needing a lot of bandwidth from the Scrum Master.

The post Antipattern – Scrum Master the (over) protector of the Team appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Scrum Master should solve all impediments

• In the 2017 version of Scrum Guide the accountability of the Scrum Master was mentioned as “Removing impediments to the Development Team’s progress;”. This sentence was often misunderstood and it was assumed that Scrum Master is the one who runs around and solves impediments.
• The term “Facilitator” is commonly misunderstood as a “coordinator”. Most teams come from a waterfall background and are used to having a Project Manager. In most organizations, the Project Manager is nothing more than a PMO who coordinates and does administrative activities. The essence of facilitation is to make it easy for the team to get to conclusions and decisions. Impediment solving is only one aspect of the Facilitation.
• Most organizations implement Scrum Master as a replacement for the PMO responsibilities and expect Scrum Master to run around and solve impediments.
• From the outside, this looks to be a great idea to have developers do the work and Scrum Master run around and get the administrative stuff done.

Negative Consequences of having a Scrum Master solve all impediments

• One of the fundamental elements of Scrum is “Self Management” where the team manages itself. The Scrum Master’s job is to teach the team to be self managed and cross functional so that they can get the work done.
• Team members other than the Scrum Master might be better qualified to solve an impediment
• People often then shrug off their accountability and expect scrum Master to be the PMO and even solve problems which they could solve internally
• Problems are often too complex to be solved by one person and therefore Scrum Master may not be the correct person to solve the problem
• Viewing an impediment from different angles helps to find effective solutions
• Many problems have to do with the way how people work together, solving such a problem cannot be done by one person

What could be done to avoid this anti-pattern

• The first line of defence for the team should be the team members themselves. The Scrum Master must teach the team to do this and not push everything into Scrum Master’s plate
• The Scrum Master should not get overloaded with solving impediments. The Scrum Master should be an observer, a coach and making sure that facilitation is done.
• For impediments which actually need Scrum Master’s help, only those Scrum Master should focus his/her attention on.
• Scrum Master should use his anticipation skills to anticipate issues so that the team can start looking for solutions a little bit in advance.
• In short, Scrum Master should become a coach and facilitator rather than just being a PMO.
• To clarify the actual accountability of Scrum Master with regards to impediment solving, the sentence has been reworded in the 2020 version of Scrum Guide to “Causing the removal of impediments to the Scrum Team’s progress” – which essentially means that it is not necessary that everyone just dumps all impediment solving on the shoulders of the Scrum Master.

The post Anti Pattern – Scrum Master the solver of all impediments appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Sprint Zero seems a good idea

When the team start work the team observes these typical problems

• There is no reasonable Product Backlog from which a Sprint Backlog can be created.
• Designs are not good enough to start
• Architecture decisions are often delayed

Team often struggles to create a usable product increment during the first Sprint. Often then, the teams starts with a Sprint Zero so that a usable product increment may not be expected from the team.

At the outset, it looks to be a great idea – especially those who have come from a waterfall mindset and are used to doing a lot of preparation before beginning a project.

Negative consequences of Sprint Zero

Sprint Zero is often considered an agile-sounding term for pre-Sprint preparation work where no increment of product value is provided at all. In reality, the whole intent of the Sprint is lost. To be a Sprint, something of value must be delivered in a clearly time-boxed fashion.

What could be done instead of Sprint Zero

• In Agile, we believe in just-in-time work. However, in reality this may increase the risk. Hence we should start thinking about the work (which includes designs, architectures, refinement of PB) 2-3 sprints in advance. Not too early, and not too late.
• Weak product management results in this anti-pattern. Agile does not mean that we don’t have planning. There is a lot of planning in agile. However, the planning is done such that the team has enough work for the next 2-3 sprints. Not having decisions ready, not having a product backlog ready often causes the team to resort to this type of anti-pattern.
• Critical Architecture decisions, critical design decisions, critical business decisions need to be identified. They may become show-stoppers later and the team may not have enough work for the next sprint.

The post Sprint Zero – An Anti Pattern appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Hardening Sprint seems a good idea?

Scrum Teams are under constant pressure to deliver features. The stakeholders and Product Owners often push the Developers for going to production as soon as possible. 

In these situations, the developers often postpone a lot of work to be done later. Examples include – documentation, code cleanup, defect fixing, commenting of code, hard-coding, bypassing checks etc.

Then the Scrum team introduces a “Hardening Sprint” after 4-5 Sprints to take care of all these pending activities. Therefore introducing Hardening Sprints is generally considered a good idea by a lot of teams.

Negative consequences of Hardening Sprint

User of Hardening Sprint introduces following problems

• Pending work increases. Many times the Hardening Sprint does not get taken and the work just keeps accumulating
• It becomes more and more difficult to tidy up the mess
• Teams end up forgetting things later on
• Increase in the possibility of the defects since things get fixed later

What could be done instead of Hardening Sprint

• Follow the agile principle of “Simplicity” – the art of maximizing the work not done. That is, don’t push more features. Try to complete a lesser number of features with all things done.
• Slow down – focus on quality rather than speed
• Make the Definition of Done more stringent
• Focus on engineering practices such as Automations, CI/CD, Automations, TDD
• Say NO to a hardening sprint. Do not keep pending activities.

The post Hardening Sprint – An Anti Pattern appeared first on World Of Agile.