Being a Scrum Master for Multiple Teams: Why It Happens, What It Breaks, and How to Make It Work

Being a Scrum Master for Multiple Teams – Is it possible? Can it work? and rather “How to make it work?” – In almost every organization I’ve worked with, this question eventually comes up:

“Can one Scrum Master handle multiple teams?” And more often than not—the answer is already assumed to be yes.

Not because it’s ideal. But because it feels practical… It seems more efficient

Let’s be clear about why this model exists before we jump into whether it works.

Why Organizations Assign One Scrum Master to Multiple Teams

In my experience across large agile transformations, this decision usually comes from one (or more) of these reasons:

1. Budget Constraints

Agile transformations are often expected to be “lean.”

So instead of hiring one  Scrum Master per team, Organizations go for one Scrum Master for 2–3 teams. On paper, it looks efficient.

2. Misunderstanding the Scrum Master Role

This is still very common. Often leadership sees the Scrum Master as:

• A meeting facilitator
• A Jira admin
• A status tracker

Then naturally, they ask – “Why can’t one person handle multiple teams?”

3. “Senior = Can Handle More”

I’ve seen this especially with Senior Scrum Masters or Experienced Developers stepping into SM roles. The logic then becomes: “They’re experienced, so they should handle more teams.”

Experience does increase effectiveness. But it doesn’t multiply time or presence.

4. Mature Teams (At Least Perception of It)

Sometimes the assumption is: “These teams are “doing” Agile for long time now. They don’t need much support.” Sometimes this is true. But many times it’s just… optimistic.

When  Organizations Assign One Scrum Master to Multiple Teams

 – What Actually Happens?

Let me share something I’ve seen repeatedly. I once worked with an organization where one Scrum Master supported three teams.

• Team A was high-performing
• Team B was struggling with dependencies
• Team C was newly formed

Guess where most of the Scrum Master’s time went?

Team C (firefighting)
Then Team B (escalations)

And Team A? -They slowly drifted. Retrospectives became routine … Improvement slowed down ….Small issues went unnoticed

Nothing broke immediately. But growth stalled.

That’s the subtle risk in this model.

Challenges You Should Expect

Despite of all this, it is inevitable that you will have to look after more than one team at a time – Below I will give some challenges you should expect in the situation

1. Context Switching Is Real

Every team has:

• Different stakeholders and Energy
• Different maturity
• Different challenges (geographical distribution / domain complexities / cultural differences /product lifecycle stage.. etc)

Switching between them isn’t just logistical—it is a definite mental stress. And this stress builds up. Slowly but surely.

2. You May Move from Deep Impact to Surface Coverage

When you work with many teams, you run the risk of spreading yourself too thin. Then, instead of:

• Coaching behaviors
• Enabling ownership
• Driving systemic improvements

You may end up:

• Just Attending Events – and this is when the Scrum Events start to turn into mere “ceremonies”
• Focusing on the obvious, on the surface “blockers” – you now lack bandwidth to go deeper to seek and address the true impediments. Read this article to understand how (and more importantly – “why” to differentiate between blocker and impediment. 

3. Your Availability Becomes a Bottleneck

Teams don’t need you all the time. But when they do need you—it’s usually urgent. With multiple teams, you’re often:

• In another meeting
• Context-switching
• Or already overloaded

Slowly the teams start to normalize you being less available to them… and that often leads ti them accepting the waiting game.

4. Impediments Take Longer to Resolve

The real work of a Scrum Master is not in meetings or Scrum Events. It’s in:

• Following through
• Influencing stakeholders
• Removing systemic blockers

And that work suffers when attention is split.

5. Energy Drain (The Silent One)

When you are working as a Scrum master for more than one team, you are running from one meeting to other …

• Daily Scrum for Team  A
• Refinement sessions for Team B
• Reviews for Team C
• Retrospectives  for Team A

The cycle goes on and on without a break. This is where even experienced Scrum Masters start feeling stretched.

What Helps When One Scrum Master Is Supporting Multiple Teams

Scrum Guide says Scrum Master is accountable for helping the Scrum Team become more effective. When you work with multiple teams as a Scrum Master, that expectations will still remain. Below I have given some tips that help

1  Shared Product Context

If there’s one factor that significantly improves the chances of success in a multi-team setup, it’s this:  The teams are working on the same or closely related products. I’ve seen this make a huge difference.

When teams are aligned around:

• The same product
• A shared customer journey
• Interconnected features

The Scrum Master gains leverage:

• Better context retention (less mental switching)
• Stronger stakeholder alignment
• Easier dependency management
• More meaningful cross-team coaching

I once worked with three teams building different modules of the same platform.

Instead of treating them as separate units, we:

• Ran joint backlog refinement for shared features
• Aligned retrospectives occasionally to spot system-level issues
• Visualized dependencies across both teams

The result?

Less duplication
Faster decision-making
And significantly smoother flow

Compare that to supporting unrelated teams (say, one in payments and another in HR systems)—the cognitive load and disconnect are much higher.

So if organizations must assign one Scrum Master to multiple teams, product alignment is a powerful enabler.

2. Shift from “Team Scrum Master” to “System Enabler”

If you try to give equal time to all teams—you’ll struggle. Instead:

• Look for patterns across teams
• Solve problems at the system level
• Reduce recurring issues

This is where Kanban thinking (flow, bottlenecks) becomes incredibly valuable.

3. Be Intentional About Where You Go Deep

Not all teams need the same level of attention.

I usually ask:

• Which team is at risk?
• Which team can self-sustain?
• Where will my effort create the most impact?

Then I adjust accordingly.

4. Build Capability Inside the Team

One of the biggest shifts:

Stop being the center of everything.

Instead:

• Encourage team members to facilitate
• Build ownership of Scrum Events
• Develop internal champions

If everything depends on you—you won’t scale. Remember, as a Scrum Master you are accountable from Scrum Team effectiveness – and you are NOT accountable to do everything yourself

5. Make Retrospectives Non-Negotiable

If there’s one place to invest your energies deeply—it’s for Sprint Retrospectives

Even with multiple teams:

• Make every effort to keep retrospectives meaningful
• Focus on real actionable improvement items
• Follow through on actions

This is where the teams start being more effective.

6. Use Visualization to Your Advantage

Across teams:

• Visualize bottlenecks
• Highlight delays
• Track dependencies

When leaders see the system, conversations change. Teams delivering value is more important  than teams just “doing work”

7. Protect  Your Own Energy and bandwodth Ruthlessly

This is rarely talked about—but critical.

• Avoid stacking heavy sessions back-to-back – if you are not at your best, that will impact the value you bring to the table.
• Create thinking space (not just meeting space)  – create some bandwidth for your self to  just think
• Protect time for actual coaching work

You’re not effective when you’re exhausted.

Final Thoughts On Being a Scrum Master for Multiple Teams….

Being a Scrum Master for multiple teams isn’t about doing more.

It’s about:

• Establishing Synergy
• Empowering Teams
• Enabling systems
• And using context (especially shared product context) to your advantage

When done thoughtfully, this model can actually elevate the Scrum Master role from team facilitator to organizational change agent.

The post Being a Scrum Master for Multiple Teams appeared first on World Of Agile.

How a Scrum Master Can Help the Product Owner Succeed

Discover How a Scrum Master Can Help the Product Owner to succeed. Product Owners face complex decisions daily. Get some practical tips on how Scrum Masters elevate Product Owners. Learn how Scrum Masters empower Product Owners to move from reactive execution to value-driven delivery through coaching, flow practices, and better stakeholder collaboration. This article is a part of the series describing roles and responsibilities of the Scrum Master.

Introduction: Why does the Product Owner Need Support from The Product Owner?

The role of a Product Owner is far more demanding than it appears on paper. Scrum Guide says the Product Owner has to maximize value. As such this person sits at the intersection of market forces, stakeholders, and technology. In order to balance the three, they need to constantly make decisions that balance benefits, risk, and delivery. As a Product Owner you will end up doing some

• Constantly balancing competing stakeholder expectations
• Managing and refining an ever-evolving Product Backlog
• Making high-impact prioritization decisions with incomplete information
• Bridging the gap between product vision and team execution
• Handling pressure to deliver value quickly while ensuring alignment

In fast-paced and complex environments, this responsibility can quickly become overwhelming. This pressure often pushes Product Owners into working in a reactive mode rather than enabling strategic, outcome-driven thinking. This is where the Scrum Master becomes a critical partner. Beyond facilitating events, an effective Scrum Master enables the Product Owner through coaching, structure, and flow—helping them move from reactive execution to intentional value delivery. Below, I have articulated some key areas where the Scrum Master supports the Product Owner

What Can the Scrum Master Do To Help the Product Owner 

Teaching Scrum for Better Product Ownership

One of the most important ways a Scrum Master supports a Product Owner is through teaching Scrum. Product Owners usually operate in complex environments where misunderstandings about roles and expectations are common.  Scrum Master teaches Scrum to Product Owners, stakeholders and Developers

• Teaching Scrum to Product Owners – Product Owners often are used to working in traditional ways of working. Helping them understand and implement self-management helps Developers to deliver value more effectively. Of Course, this, in turn, helps the Product Owner- our value custodian
• Teaching Scrum to Developers – Similar to the Product Owners, Developers also need teaching and hand-holding to work in Scrum. This obviously helps them deliver value more effectively.
• Teaching Scrum to Stakeholders – Organizations usually are diligent about teaching to Developers and Product Owners. But we often ignore teaching Scrum to stakeholders. But Scrum represents a very different way of working for the stakeholders. Like the Product Owners, the stakeholders are often used to working independently in the traditional way of working. They are not used to working hand in glove with Developers and the Product Owner. We see this often when the stakeholders resist requests for frequent refinement sessions and regularly scheduled Sprint Reviews.

Thus, The Scrum Master helps the Product Owner—and the broader ecosystem of Developers and stakeholders—understand how Scrum works in practice. This includes reinforcing accountabilities, clarifying boundaries, and fostering a shared understanding of value delivery. When the Scrum Master helps to build this alignment, it helps the Product Owner to focus on Value delivery.

Facilitating Effective Product Backlog Refinement

Product Backlog refinement helps ideas evolve into actionable work. But, without proper facilitation, it easily becomes inefficient or unfocused. The Scrum Master helps to keep refinement sessions structured, time-boxed, and collaborative. They help the team focus on clarity, alignment, and readiness. This helps to ensure the backlog items are well understood and appropriately sized When Scrum helps with effective Product Backlog Refinement, the Product Owner can concentrate on defining what needs to be built Here are some tips to help with effective Product Backlog Management

 Strengthen the  Product Backlog Management

Effective backlog management is more than maintaining a list of user stories. It is  about continuously aligning work with value. Scrum Masters support Product Owners by introducing techniques such as story slicing, outcome-oriented thinking, and maintaining appropriate levels of detail. They help ensure that near-term work is clear while avoiding over-investment in distant priorities. The result is a backlog that remains dynamic, relevant, and value-driven.

Support Prioritization and Decision-Making

Prioritization is one of the most challenging aspects of the Product Owner role. Every decision involves trade-offs and invites in depth often conflicting discussions. The Scrum Master does not make decisions, instead they enhance decision quality. They introduce techniques like impact mapping, cost of delay, or WSJF. These techniques provide structured ways to evaluate priorities. This helps the Product Owner shift from reactive prioritization to more intentional and informed decision-making.

Enhance Stakeholder Collaboration

Stakeholders are essential to product success—but unmanaged interactions sometimes overwhelm the Product Owner. The Scrum Master helps design effective engagement models, ensuring that feedback is timely, relevant, and constructive. They facilitate meaningful Sprint Reviews and coach stakeholders on how to collaborate with the team. By creating structured communication channels, the Scrum Master enables better alignment without constant disruption.

Help the Product Owner to Align Product Vision with Outcomes

A common challenge for Product Owners is how to maintain an alignment between long-term vision and day-to-day backlog work. Scrum Masters help bridge this gap by encouraging outcome-driven thinking. They facilitate alignment with business goals, OKRs, or value streams, ensuring that backlog items contribute to meaningful outcomes. This strengthens the Product Owner’s ability to communicate direction and purpose.

Improving Flow and Delivery Predictability

Incorporating flow-based practices can significantly improve delivery outcomes. Scrum Masters help by introducing Kanban practices such as visualizing work, limiting work in progress, and tracking flow metrics like cycle time. These practices provide valuable insights into delivery patterns. For the Product Owner, this means better forecasting, clearer expectations, and more predictable delivery.

Removing Organizational Impediments

Product Owners face many challenges that go beyond the team level. Scrum Masters work to identify and remove these systemic impediments. Some examples are multi-team dependencies, governance delays, or organizational silos. Scrum Masters work within the organisational constraints and create an environment where the Product Owner can operate more effectively.

Fostering Strong Collaboration with the Team

Product success depends on collaboration between the Product Owner and Developers. Scrum Masters coach both sides to move away from a “handoff” mindset toward shared ownership. They encourage continuous dialogue, joint problem-solving, and active participation. This leads to stronger alignment and better outcomes.

Conclusion: Scrum Masters Help the Product Owner Succeed by enabling Product Success Through Partnership

Ultimately, the effectiveness of a Product Owner is deeply influenced by the support system around them—and the Scrum Master is central to that system. Scrum Masters go beyond facilitating Scrum events. A skilled Scrum Master elevates the Product Owner’s ability to think strategically, act decisively. They help the Product Owner collaborate effectively with Developers as well as Stakeholders. A Scrum Master combines coaching, facilitation, and flow-based practices to help shift Product Owners from reactive execution to value-driven delivery. This partnership can be a true force multiplier. When the Scrum Master and the Product Owners work in tandem, they go beyond delivering increments. Together, they enable outcomes, accelerate learning, and drive meaningful business impact.    

The post How a Scrum Master Can Help the Product Owner appeared first on World Of Agile.

Does Agile Need Project Managers? A Reality Check

Introduction: Agile and Project Managers

“Agile doesn’t need Project Managers.” Or “Project Managers are getting obsolete”

I often hear this statement. People often say this with conviction, sometimes with relief, and occasionally with confusion.

Over the last decade or so frameworks like Scrum and Kanban have become more famous. And that brought a shift away from traditional roles. Scrum, in particular, explicitly defines only three accountabilities: Product Owner, Scrum Master, and Developers. Scrum Guide does NOT mention a project manager at all.

And just like that, many organizations concluded: the Project Manager role is obsolete. We do not need Project Managers any longer…..

But is that the right conclusion ? — Or have we misunderstood what Agile is actually trying to change?

I do not plan to defend job titles in this article. Instead, I want to discuss and examine the ground reality. I want to talk about what actually happens in Agile projects beyond theory, certifications, and frameworks.

Where Did This Question Come From?

To understand the confusion, we need to go back to traditional project management.

In a traditional setup, the Project Manager was the central authority. This person was responsible to plan, track, report, manage the risk management, communicate with team and stakeholder and above all ensure value delivery.

With so much to do, project managers often became a bottle neck.

Agile challenged this model.

Instead of centralized control, Agile emphasized:

• Self-managed teams
• Collaboration over hierarchy
• Adaptability over rigid planning

In doing so, Agile (more specifically Scrum) didn’t explicitly include the Project Manager role.

Many interpreted  this as “no need for project managers.”

That’s a dangerous assumption and a myth!

While Agile removed the role as a command-and-control authority, it did not eliminate the responsibilities that ensure delivery.

What Agile Frameworks Actually do Say about Project Management

Now Let’s separate the myth from reality.

We saw that Scrum did not specifically ask for Project Managers

What Does Scrum Say about Project Managers?

Scrum defines accountabilities clearly—and Project Manager isn’t one of them. But Scrum operates at the team level. It assumes a relatively contained environment where a single team can deliver value incrementally.

It does not address:

• Cross-team dependencies
• Complex stakeholder landscapes
• Organizational constraints

Kanban and the Project Manager
Kanban goes even further. It doesn’t mandate specific roles at all. Kanban focuses on evolutionary change, improving  the flow via work visualisation, and limiting work in progress.

But again, it assumes a system where flow can be managed effectively. Someone still needs to ensure alignment, remove bottlenecks, and manage expectations. These days, roles emerge for flow management in kanban. Some common  roles are  the Service Delivery Manager (SDM)(who manages workflow and removes bottlenecks – similar to a Scrum Master), and the Service Request Manager (SRM) (who manages the backlog and prioritizes customer requests – like a Product Owner)

SAFe (Scaled Agile Framework) and the Project Manager

SAFe also does not have a designated role called a Project manager. However,  SAFe does include roles like  the Release Train Engineer, the  Product Manager, and the System Architect.

Question is Why?

Because at scale, coordination and alignment is critical. Dependencies multiply. Stakeholders increase. Complexity grows.

And suddenly, the need for overarching thinking becomes undeniable.

The Reality of Agile Projects on the Ground

In real organizations, Agile projects today rarely operate in isolation. They involve:

• Multiple teams working on shared outcomes
• Dependencies across systems and functions
• Stakeholders with competing priorities
• Pressure to deliver faster, with quality

Now ask yourself:

• Who ensures that all of this comes together?
• Who aligns teams when priorities conflict?
• Who manages risks that span across teams?
• Who communicates with stakeholders beyond the team level?
• Who takes accountability for multi team integrated delivery outcomes?

Self-organizing teams are powerful—but they are not designed to solve organizational complexity on their own.

 So Who Actually Does this Work?

Even in Agile environments, the following responsibilities don’t disappear:

• Stakeholder Management – Aligning expectations, managing communication
• Dependency Management – Coordinating across teams and systems
• Risk Management – Identifying and mitigating delivery risks
• Planning at Scale – Beyond sprint-level planning
• Delivery Accountability – Ensuring outcomes, not just outputs

What happens on ground? These responsibilities are often:

• Distributed
• Unclear
• Or silently pushed onto Scrum Masters, Product Owners, or senior team members

This creates confusion—and sometimes, burnout. Read this article to understand the Scrum Accountabilities and what happens when we ask people to wear multiple hats  

The Emergence of the Agile Project Manager

In many organizations, something interesting happens. The role doesn’t disappear—it evolves. The title may not be “Project Manager” anymore. Instead, the new title can be:

• Delivery Manager
• Program Manager
• Agile Project Manager
• Release Train Engineer

But the essence remains the same:
Someone is responsible to connect the dots.

When you assume the title of an Agile e Project Manager, you do not assume a command-and-control authority.

Instead, you become a

• A Facilitator of alignment
• A Enabler of flow
• A Manager of complexity

and

• An Influencer without formal authority

When Agile Projects Fail Without Project Management

Let’s be honest—many Agile transformations struggle.

Not because Agile doesn’t work, but because critical responsibilities are ignored.

Common patterns include:

• Teams delivering increments that don’t align with business outcomes
• Dependencies causing delays and frustration
• Stakeholders feeling disconnected and dissatisfied
• Lack of clear ownership for delivery risks

In such cases, Agile doesn’t feel empowering—it feels chaotic.

And often, the missing piece is not process—it’s project-level thinking and coordination.

What Makes an Agile Project Manager Different

If Agile still needs project management, then what changes?

Everything.

The Agile Project Manager is not:

• A task assigner
• A status tracker
• A gatekeeper

Instead, they:

• Enable flow, not control work
• Facilitate decisions, not impose them
• Influence stakeholders, not manage them through authority
• Focus on outcomes, not just timelines

It’s a shift from control to alignment and orchestration.

Snehamayee’s Thoughts

So do you need an Agile Project Manager? The answer is: it depends.

You may not need a dedicated Project Manager when:

• You have a single, small, co-located team
• Dependencies are minimal
• Stakeholders are closely aligned

But as complexity increases—

• Multiple teams
• Distributed environments
• High uncertainty
• Organizational constraints

—project-level coordination becomes essential.

Call it what you want, but the capability must exist.

The Bigger Problem: We’re Asking the Wrong Question

“Do Agile projects need Project Managers?” is the wrong question.

The better question is:

Do Agile projects need strong project management capabilities?

The answer is clearly yes.

Organizations don’t fail because they have Project Managers.
They fail because they lack clarity on how the role should evolve in Agile.

Conclusion: A Project Manager for an Agile Project is still relevant – You just have to align the work for Agile Realities

Agile didn’t eliminate the need for project management.

It redefined it.

The role is no longer about control—it’s about enabling alignment, managing complexity, and ensuring delivery in dynamic environments.

Whether you call it a Project Manager, Delivery Manager, or something else doesn’t matter.

What matters is this:

If no one is taking ownership of project-level responsibilities, your Agile setup is incomplete.

Reflection for you:
In your Agile projects today—who is actually handling project-level responsibilities?

The post Does Agile Need Project Managers? appeared first on World Of Agile.

Real-Life Scenarios when multiple Teams are working on the Same Product

In this section, we will look at some real-life scenarios that Scrum Team(s) often face when multiple Teams are working on the Same Product . This article is part of an ongoing series on real-life scenarios that many Scrum Teams face. Adding more teams to a product should increase speed. That’s the expectation. However, in many organisations, the opposite happens. Despite having multiple Scrum Teams working in parallel, delivery slows down, dependencies increase, and alignment becomes harder. Teams stay busy, but product progress feels inconsistent. The problem is not the number of teams—it is the complexity that comes with them. Working with multiple teams on the same product requires a different level of discipline, collaboration, and clarity. Without it, scaling Agile can quickly turn into scaling confusion. Based on my experience working with multi-team environments across Scrum, SAFe, and Kanban setups, here are some real-life scenarios that frequently emerge.

1. “We are done” (But Others cannot use it!!)

Team A completes their work and marks their stories as “Done.” However, when Team B tries to use the same functionality, they run into issues—missing APIs, incomplete validations, and inconsistent behaviour. From Team A’s perspective, the work is complete. From Team B’s perspective, it is not usable.

Snehamayee’s perspective

What’s happening here? Each team delivers their work with their own interpretation of what “Done” means. There is a clear lack of a shared understanding at the product level. Impact: Work appears complete on dashboards, but real progress is not seen. Instead, the teams struggle with rework, delays, and frustration What we can do?

• A shared Definition of Done across teams is critical. It should include integration, usability by other teams, and alignment with product-level quality standards. “Done” should mean usable—not just complete within a team boundary.
• Integrated Solution level or Product level reviews – SAFe (Scaled Agile Framework ) recommends regular System demos. These are integrated demos – These will enable teams to “see” how their work is being used by other teams. These demos also help the teams as they encourage collaboration

2. Dependency Chaos Between Teams

A very common situation in multi-team setups is when one team’s progress depends heavily on another. You often hear statements like: “We can’t start until Team B finishes their part.” Or “We’re blocked waiting for the API from Team C.” Snehamayee’s perspective What’s happening here? Some possible reasons are

• Component Teams -Teams are often structured around components rather than features. This leads to tight coupling between teams.
• Inefficient work slicing – In addition, the work slicing (splitting work across teams) often creates additional dependencies across team boundaries

Impact: Planning becomes uncertain, commitments become unreliable, and teams lose their ability to deliver independently. Instead of enabling speed, multiple teams create bottlenecks. What we can do?  

• Reducing dependencies should be a continuous focus. This may involve rethinking backlog slicing, re-assignment of work, or even restructuring teams toward more feature-oriented ownership.
• Dependency Board – Visually tracking the multi-team dependencies will help the teams identify critical path to monitor, bottlenecks to be aware about and trigger remedial actions in advance to reduce dependencies. Another SAFe technique the ART planning board will help.
• Design Feature Teams –Teams that are designed to deliver end to end value rather than a specific component help with easier coupling

3. Conflicting Priorities Across Teams

In another setup, each team appears busy and productive. However, when viewed from a product perspective, progress is slow and scattered. Different teams work on different priorities—some on new features, others on technical improvements, and some addressing stakeholder requests.

Snehamayee’s perspective

What’s happening here?

There is no clear alignment at the product level. Teams optimize for their own backlog rather than a shared product goal.

Impact: High activity does not translate into meaningful outcomes. Work gets fragmented, and the product evolves in an inconsistent manner. What we can do?

• Clear product-level prioritization is essential. Whether through a single Product Owner, a Chief Product Owner, or a well-aligned Product Management function, teams need a shared understanding of what matters most.
• A cross-domain planning session – A common planning session across teams will help the teams to align their priorities and expectations.

4. Integration Becomes a Nightmare

Integration of work is one of the most common challenges for the multi-team product. Each team develops and tests its work independently. Everything works fine within team boundaries. However, when all components come together, issues start to surface—unexpected defects, incompatible interfaces, and performance problems.

Snehamayee’s perspective

What’s happening here?

Integration happens too late. Teams work in silos with limited visibility into how their work interacts with others.

Impact: Integration risks accumulate over time. On top,  these integration risks will often surface at the worst possible moment—close to release timelines.

What we can do?

• Frequent integration is key. Practices such as continuous integration, shared environments, and automated testing help reduce surprises. Integration should not be treated as a separate phase—it should be part of everyday development.
• A common Sprint Duration – A common Sprint Duration will provide a cadence needed for frequent integration
• Regular Integrated demos Or System demos as defined by SAFe will help. These demos help to enforce regular integration

5. Ownership Confusion – “Who Owns This?”

In multi-team environments, features often span across teams. This creates situations where responsibility is unclear. When an issue arises, the response is often: “This part belongs to Team A.” or “That integration is handled by Team B.” or “This is not our responsibility”

Snehamayee’s perspective

What’s happening here?

Ownership is divided along component or functional lines, rather than end-to-end product outcomes.

Impact: Slow decision-making, blurred accountability and issues that take longer to resolve. In some cases, important items fall through the cracks because no team feels responsible.

What can we do? Clear ownership of outcomes is critical. Even if multiple teams contribute, there should be clarity on who is accountable for delivering the feature end-to-end. Shifting toward feature ownership rather than component ownership can help address this challenge.

Final Thoughts on Real-Life Scenarios Faced by Scrum Teams When Multiple Teams Work on the Same Product

Working with multiple teams on the same product is not just about adding capacity(or people). It is about managing complexity. Many of the challenges discussed above are not caused by a lack of skill or effort. They arise from gaps in alignment, communication, and shared understanding. Some common issues I have seen across many customers are:

• Lack of shared standards – for example, a common integrated Definition of Done or common  quality standards
• High dependencies between teams means a tight coupling and more limitations
• Misaligned priorities lead to effort wastage and rework
• Limited focus on integration and ownership

  It takes conscious effort to address these challenges. Some tips that help are

• Better Alignment among teams by planned multi team events like structured cross-domain planning
• Establishing collaboration forums like dependency boards
• Designing feature teams that deliver end to end value and move away from component teams

Organisations that recognise and actively address these patterns are more likely to realise the true benefits of scaling Agile. Those that do not often find themselves adding more teams—but not necessarily delivering more value.    

The post Real-Life Scenarios Faced when multiple Teams are working on the Same Product appeared first on World Of Agile.

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.

Real Life Issues related to Scrum Team Velocity

In this section we are going to discuss about Real Life Issues related to Scrum Team Velocity. Velocity as a concept is not discussed explicitly in Scrum Guide. However, Velocity indeed is a commonly used development practice

The biggest challenge regarding velocity is often inconsistent or reducing velocity: If your teams are seeing a downwards trend in velocity or if the Velocity is inconsistent, some factors to consider could be

1. Inconsistent Workload and Scope Creep:

• Over ambitious Sprint Goals: Setting unrealistic or overly optimistic Sprint Goals can lead decreased productivity. In addition, Product owners often pressurize the Developers to accept more work in their zeal to deliver value. As a result, the Developers are not able to plan well.
• Scope Creep: Often the Product Owners ask the Developers to pitch in to unplanned work outside the sprint. Sometimes, they ask the Developers to accept new stories not planned in the Sprint. In these cases, unplanned work will derail sprint plans and impact velocity.
• A Product Backlog which not designed well: Sometimes, the Product Backlog items are not properly prioritized, or the Items selected in the Sprint are not broken down sufficiently. This makes it difficult for Developers to predict how much work to pull in the Sprint.

2. External Factors and Impediments:

• Technical Debt: Accumulated technical debt can make the system unpredictable. This causes a slowdown in the development work. As a result, we see reduced velocity.
• Organizational Impediments: Bureaucracy, lack of resources, or inflexible processes can create bottlenecks. These bottlenecks usually impact the Scrum Team Velocity.

3. Scrum Team Factors:

• Changes in Scrum Team: New team members can impact velocity as they adapt to the team and processes. If any existing team member moves out of the team, the remaining team members may take some time to adjust to the new reality.
• Team Motivation Levels: Low morale, burnout, or lack of motivation can negatively affect productivity.
• Communication Barriers: Poor communication can lead to misunderstandings, delays. In turn, these delays lead to decreased efficiency.

4. Misunderstanding and Misuse of Velocity:

• Focusing on the Number: Prioritizing just the velocity number over quality may lead to long-term problems. Some examples of these issues are incorrect data reporting and representation. When the Scrum Teams are solely judged on basis of Velocity – they may be tempted to slice and dice the data in order to show a project as “green”!
• Using Velocity as the sole Prediction Tool: Relying solely on past velocity to predict future performance can be misleading. Capacity mis-calulation is a very common reason velocity to appear low. Along with Valocity we should looks for
  • Available Capacity
  • Other planned work (for example, a planned release in previous Sprint may mean more time spent in Production firefights, a planned training will lead to team having less bandwidth)
  • Any widespread cultural events (for example, Diwali in India)

Overcoming the common Real Life Issues related to Scrum Team Velocity

To address these challenges, Scrum Masters can choose several strategies :

• Foster a Culture of Ongoing Improvement: Leverage the Sprint Retrospectives to identify improvement areas and implement changes. These changes then can help the Scrum Team to better Plan their work.
• Prioritize Technical Debt: Work with the Product Owners to Prioritize Tech Debt removal work. This will enable the Developers to allocate time to address technical debt to prevent it from hindering future development. As a result, over all system stability will increase.
• Effective Impediment Removal: Help the Scrum Team to actively identify and resolve impediments that impact the team’s progress.
• Promote Transparency and Open Communication: Encourage open and honest communication within the team and with stakeholders.
• Set Realistic Sprint Goals: Work with the team to set achievable goals that balance productivity and sustainability.
• Focus on Quality over Quantity: Prioritize delivering high-quality work over rushing to meet unrealistic deadlines.
• Use Velocity as a Tool, Not a Target: Use velocity to track trends and identify areas for improvement, rather than as a rigid performance metric.
• Build a Strong Team Culture: Foster a positive and supportive team culture that encourages collaboration and innovation.

Recognizing these challenges and adopting effective strategies will help Scrum Masters to assist their teams in maintaining consistent and sustainable progress, which leads to the delivery of high-quality products and services.

The post Real Life Issues related to Scrum Team Velocity appeared first on World Of Agile.

Many students ask me how to choose a pilot? To ensure success of your transformation, it is really important to choose a right pilot. Below I will give a few suggestions. These suggestions have worked for me in while choosing an Agile pilot.

1. Select a “Visible but not critical project”. It is important to choose a project that has visibility across organisation. This will make the next steps of spreading agile easier. When we select a visible project, it becomes difficult for detractors to dismiss the success. At the same time be wary of selecting mission critical projects. Too much is riding over success of such a project. In this case, the team will be less likely to experiment. The stakeholders will be even less likely to have the necessary patience.
2. Size Matters!! I usually suggest to select project which is not too large. A large project has additional scaling challenges. These become an overhead while trying to implement agile. Usually not more than 3 scrum teams is a nice rule of thumb to follow. I also caution against selecting a too small a team. Such project may also mean a success which is not as spectacular to be tooted across organisation. A really small project delivered by a small team is anyway likely to be succeeded and agile would not get the credit for the success!
3. Where possible avoid added complicating factors. If at all possible, it is better to avoid a project with unnecessary complications. Some examples can be, technology which is too strange to the team, a team that is greatly distributed (more than 3 locations) or a team that is too new and still in “forming /storming” stage. Changing way of work to Scrum is anyway stressful, it is best to avoid further stress. 
4. Select a project that intuitively needs agile It’s best to select a project that has need to evolve requirements – in other words it’s best to have a pilot for starting a brand-new product. It will allow the inherent agile qualities to shine. At the same time, we would avoid added complications of a monolithic architecture or a legacy code base that no one fully understands.
5. On board the champions – Identify your supporters early and include them in your pilot. These people are any way convinced and they will work hard to prove the concept.
6. Avoid The detractors – In the same vein, it is usually prudent to avoid strong nay Sayers. They usually will come on board when they see the pilot succeed. This will reduce the stress of having resistance along every step of pilot

The post Choosing Right Pilot for Agile Implementation appeared first on World Of Agile.

There are Two ways of looking at our work. The primary constraints of any project include Scope, Cost, Time and Quality. I have represented them in the following diagram as “The Traditional Way” and ” The New Way”.

The Traditional way : This is the Scope driven way of looking at the work. In the traditional way, Scope is always considered central. Assuming that Quality is non-compromisable, the other two factors are varied – time and cost. That is one of the major reasons why there are project delays and cost overruns.

The New Way : In the new way its all about Simplicity (Agile Manifesto principle 10 – “Simplicity, the art of maximizing the amount of work not done is essential). In this way, more importance is given to completing on time and in budget. Scope is considered flexible to the extent that we give what the customer wants. Of course there has to be a structure around how we give variable scope and that is described in Scrum/XP/DSDM etc. This is also based on the fact that most customers don’t really care about all scope. Its about 20% of the Scope giving 80% of the value. Thus Agile frameworks focus on Value rather than Scope – and value could be delivered on giving the Scope that customer values.

The Struggle with writing contracts in the New Way

One of the common dilemma faced by people executing Agile implementations is the way they structure the contracts. Most agile frameworks like Scrum are based on “Timebox” principle which means that the time is not variable. However, most customer-vendor relationship work on fixed-scope-fixed-cost contract (typically called Fixed Price Contracts). With the change of mindset to fixing up the “Timebox”, one might think that the contract type that we are talking about fixed-time-fixed-cost-fixed-scope. Now thats a recipe for a poor quality. If you fix up Scope, Cost, Time then the people will end up varying quality.

The most practical way to structuring the contracts to work in the “New Way”

The most common type of contract used in Scrum is either time and materials (T&M) or a pseudo-fixed price. Pseudo-fixed price is just a T&M contract with the cost of each sprint defined as resource hours multiplied by the rate. The true fixed-price contracts are the ones for which the utmost care has to be taken; otherwise, the team will find itself working on a worse-than-Waterfall project.

I have lead many projects in Scrum and dynamic systems development management in Europe and have observed some common mistakes managers make in writing a fixed-price Scrum contract. For example, Scrum contracts are written in the same way as traditional contracts, and the managers add only the “will be done in Scrum methods” line in the contract. In the traditional contract, the cost and time are always variables, with some change of budget or contingency added. However, the customer argues that because it’s Scrum, and that the concept of timebox applies, the contingency and the change budget inherently get removed. This makes the contract fixed time, fixed cost, and, of course, fixed scope.

I suggest the following modifications to traditional fixed-price contracts to make them applicable to Scrum:

1. Modify the scope section by using the MoSCoW principle (the Musts, the Shoulds, the Coulds, and the Woulds).
2. Use the Shoulds and Coulds as a scope tolerance when the customer asks for changes to be incorporated. Obviously, you will adapt to the customer changes, but then the customer should also understand that the scope cannot be fixed and that there is always a cost for the change. It is just that the cost of the change is taken in terms of knocking off some of the scope from the Shoulds or the Coulds.
3. Include a condition that states that the scope is flexible, but when it is added to the Must section, it is fixed. However, the scope written in the Should and Could section is “negotiated” based on the changes suggested by the customer.

Leave some room for the negotiation of scope in the contract. Otherwise, you will find your team doing a fixed-price, fixed-scope, and fixed-time contract, which would be really unfortunate for the team.

This Article was published on Scrum Alliance on 30-Dec-2015 and link to this article is

https://www.scrumalliance.org/community/member-articles/1301

The post Writing a Variable Scope Contract/SoW appeared first on World Of Agile.

I was part of the vendor team for a large Dutch bank where work was being done in the traditional framework, using multiple vendors. The financial industry had changed drastically from 2008 onward due to a series of events such as separation of banks, mergers of banks, banks going bankrupt, and nationalizations. It was necessary to move to Agile to adapt to the frequently changing requirements.

We (customer and suppliers) discussed and adjusted many things in the existing master contracts to enable all of us to work in the new way.

End-to-end contract

A typical way we divided work was to have one vendor do the requirements gathering, another do the development, another the testing, and perhaps another the deployments. This resulted in a horizontal split of responsibilities. The problem with this way of contracting was that none of the vendors had end-to-end accountability.

We agreed that in the new way of working, end-to-end accountability and ownership of the project was essential. The master contract was adjusted to have a vertical split of the work rather than a horizontal split. This involved a painful exercise of transitioning development, testing, and requirements work from one vendor to another; however, once the exercise was complete, it ensured end-to-end accountability.

Quality (an end-to-end responsibility of the development vendor)

The development vendor was accountable for development and testing end-to-end. The KPIs were adjusted in the contracts from development/testing KPIs to end-to-end delivery KPIs.

Monthly iteration-based pricing

Pricing models had to evolve from the traditional fixed price-based pricing or time and materials. The pricing in the new way had to be conducive to Agile. The new pricing structure was iteration based, whereby a fixed price per iteration (monthly) was agreed on between the vendors and customers.

Up-front involvement of the vendors

The new way of working meant that the vendors had to work more closely with business. The openness improved as vendors moved upstream with requirements gathering and interactions with business. The contract involved changes to the scope of the vendors’ work, with involvement in the requirements gathering phase.

Committed work to vendors

The new contract provided commitment of work to vendors for a period of two years. This ensured that vendors did not need to worry about the day-to-day work and also ensured that there were fewer tussles among vendors to secure more work. Thus, communication also improved between vendors and the customer, thereby increasing trust between them.

Multivendor business KPIs

Instead of focusing only on the operational KPIs, business KPIs were introduced. This ensured that all vendors were focused on the business-end satisfaction instead of only on the operational aspects of delivering projects.

These items were some of the contractual adjustments we made. However, it must be said that the major part of the changes involved a thought-process shift among the vendors, customers, vendor management teams, and senior management.

This article was published on scrumalliance on 29 sep 2016 – https://www.scrumalliance.org/community/member-articles/1602

The post Adjusting Master Contracts during Agile Transformations appeared first on World Of Agile.

The customer-supplier relationship is a reality for suppliers based in countries such as India, China, or the Southeast Asian countries. I was part of the leadership team of an India-based supplier that brought about a transformational change in a large bank in the Netherlands. One of the things that we (supplier and customer) focused on to get the team to concentrate on the end goal was end-user satisfaction through the implementation of a “one-team” culture.

Senior management buy-in

All of us on the leadership teams (supplier and customer) realized that an Agile transformation is not achievable if only the development teams were practicing Agile. The key was to have management align with the Agile thought process. This involved training management and opening discussions between key leaders from the supplier as well as customers. I was lucky to have worked with a few of the great thought leaders from the Dutch bank who started thinking of all the suppliers as “one integrated team” (way beyond just being a partner who delivers products for a customer). The focus changed from achieving service levels to achieving business goals, and the leadership discussions changed from service-level reviews to strategy discussions on meeting business goals through the one-team culture.

Cultural sensitization

Implementation of a one-team culture also involved cultural sensitizations. Indians had to understand the Dutch culture and the Dutch had to understand the Indian culture. This meant knowing each individual, their families, the way they work, the way they talk, the way they respond, etc. We focused on cultural sensitization sessions to understand each other’s cultures. We celebrated each other’s festivals. We appreciated each other’s games (cricket, hockey, football). Essentially, we started getting close to each other, just like one large family.

Engagement is about a “What can I do for you?” mindset

Most relationships fall apart because you always end up thinking about what you can get out of a relationship. We (the bank and suppliers) worked with our teams to make them understand that engagement and relationship are instead about what you can give to a relationship. We realized that once this is established firmly in everyone’s mind, the engagement between customer and supplier changes from a customer-supplier engagement to a one-team engagement.

Colocation at supplier’s premises

The customer and supplier teams have to work together if they want to achieve anything near to a one-team culture. We saw that the supplier teams made up 80 – 90% of the total teams. It was commercially impractical to have the supplier teams travel to the Netherlands. Doing so would have put unprecedented pressure on the budgets. We decided to have some of the key customer team members, such as product owners or architects, travel to Mumbai or Bangalore to work with the development team for extended periods. This helped reap the benefits of colocation and at the same time build a one-team culture.

Inter-supplier collaboration

When we worked on the Dutch bank projects, we realized that it was a combination of work done by multiple suppliers and customers located at multiple locations. The one-team culture is not only about taking the initiative between a customer and a supplier but also the suppliers’ efforts that must bring about a similar culture to be able to work with each other.

We had local communication channels in India among different suppliers working for the bank; that is, we tried to resolve situations between Mumbai and Delhi teams instead of taking a Mumbai–Amsterdam–Delhi channel. This involved consciously picking up a phone and speaking to other suppliers, inviting other suppliers for customer meets, having team members working from each other’s premises, etc.

Alignment with business KPIs

The initiative was to not think service-level but to think business KPIs. This was the brainchild of the bank’s CIO who inspires me even today. All suppliers and customer teams work toward the business KPIs, which was measured frequently.

We observed that most of the time, whenever it concerned a specific situation or project, it was all about the perception of the business. Getting the business involved in terms of providing inputs overall and everyone (supplier and customer) taking accountability for the inputs was critical. All of us, including the suppliers and customers, put a portion of our “money on the table” and drew from it only when we delivered what was required by the business. To be fair, it was not about the money on the table, it was about getting it in our blood that we were delivering business value and business satisfaction. It was not about delivering a few projects.

Conclusion

The success of Agile beyond colocated teams lies in Agile leadership (supplier and customer) accepting that the large development teams may not ever travel to the customer’s premises due to commercial and practicality reasons. Also, multicultural and multicountry customer teams are becoming the norm, and so the relationship is slowly moving from many-to-many in terms of customers and suppliers. Going forward, customers and suppliers will have to work at developing innovative ways to make supplier and customer teams work like one team to make global projects Agile and ultimately successful.

This article was published on Scrum Alliance member articles on 8th August 2016 – https://www.scrumalliance.org/community/member-articles/1540

The post One-Team Culture – A first step to being Agile appeared first on World Of Agile.