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.

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.

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.

“Change is difficult”, but “Change is inevitable”. And more importantly No Change is easy. Change is always a painful exercise. Agile Transformation touches the life of people. It makes them come out of their comfort zones. Agile Transformation therefore is pervasive – people hate it.

I have seen many companies struggling with agile transformation for years. In this article, I am going to explore some of the areas why this specific change is painful. In other words, we are going to see the challenges we typically see in an agile transformation.

No Templates are available for Agile Transformation

Agile looks different for each organisation. As a result, agile transformation is unique in nature for each organization since the inherent problems itself that each organization faces are different. There is no “a proven path”. It is not really possible to plan your agile transformation as per a formula or a set of checklist items. The plan is fluid and evolves as teams become agile. This creates a problem for organisations who are used to following the “Organizational Change Management” (OCM)  way of gap analysis followed by road map creation and then the road map execution.

People hate changes

Literally speaking, Agile philosophy and scrum implementation is pervasive – people hate it. It impacts complete organisation structures, way of life, more importantly it touches people’s personal life as well. For example let us talk about the change to a developer’s life. For a developer, the way you code, the way you test changes, the way you integrate changes, the way you present your problems daily to your own team-mates etc. This means people have to change the behaviour in terms of coding, testing and integrating. The accountability on the team members becomes very important. Its like saying you put someone with a spot-light on him/her all the time and expecting him/her to behave/work in the same way. No, the life is going to change drastically. One has to start behaving differently and one has to start taking accountability differently. This touches people’s day-to-day life.

Agile transformation is an ongoing exercise – it never ends 

Agile Transformation is a journey and not a destination. So, the Agile transformation never really ends. It makes measuring your success difficult. Also, the team is likely to lose their moral when they realize they will never be done.

Mindset Change over Operational Change

Agile means paradigm shift to our way of working. Over the years we believed that principles like specialization, ironclad role segregation as well as meticulous plan based execution were the cornerstones of successful project delivery. “Process over people” was our mantra. Stringent processes and defined control points were put in to compensate for human inefficiencies and imperfections. Agile on other hand, puts the responsibility back on people who are executing the project. It expects the teams to step up. It needs management  to trust the teams and have a mind set of supporting and not controlling. These changed mindset expectations are often the most difficult to implement.

Everyone’s Buy-in is required for Agile Transformation – Top down and bottom up

Many organisations are inherently top down or bottom up .In some organizations things get done when boss says so. On the other end of the spectrum some organisations change only when the teams want to. For Agile to succeed, neither approach is enough by itself. It will need a combination of bottom up and top down change approach for Agile to succeed.

The post Agile Transformation Challenges appeared first on World Of Agile.

When you do transformation programs, most of you will hear these statement

• “we were delivering projects before, we will continue to deliver projects … how much difference a mere ‘way of work’ can bring?”
• “All this agile and stuff is just a new name for the same old thing. It wont solve my problems“
• “I am doing all this Agile Transformation and stuff because my customer expects me to use the word – Agile”
• “I don’t believe in all this Agile Transformation and Stuff, however, if I don’t use these words and jargons, I will be left behind – And I need the god-damn promotion”

Many of us have come across this resistance when people don’t perceive any real value to them by going agile. They believe 

I have had some of my most notable successes, when I shifted the focus away from agile structure ( the events, artefacts and rules) to agile values and principles. I ask the stake holders a simple question 

“List some of your pain points in current way of project execution” 

Almost everyone has a long list of items that they claim are painful. I then move along further – In an ideal world – how these painful items would change? After I manage to do chip at the usual reluctance, we get to the meat – people start listing out things that they believe will help. Now we are in business. We then identify items that will bring most value to the organizations. These then become the value objectives for the transformations.

Some points to keep in mind are

• Make sure that the items you identify, are adding real business value to stakeholders. Its easy to have items that describe the behaviour and not the result. We all are used to tracking progress based on activities completed not results achieved. For example “code review done” is a behaviour – the value can be “zero defect production release”.
• Items on the Improvement Backlog should be quantified and you agree on measurable acceptance criteria before the item is taken up for execution. “10% improvement in time to market” is a better objective than “reduction in delays”
• When the Skeptical stakeholders see that their real problems are getting addressed, and more importantly they are able to project the results to their bosses, they feel happy in trying out the next set of items.
• It is important to keep the interest of the stakeholders, otherwise they lose interest quickly. Short sprints that show at least some measurable results is the best way to keep their interest alive and kicking.

The post Define Tangible Agile Transformation Items with concrete Business Value appeared first on World Of Agile.

Issue with Big-Bang Agile Transformation

Most Agile Transformations start off as bing-bang implementations spanning across multiple years. Most transformations result in a lot of heartburn and a loss-of-focus since no tangible result get achieved in a short term. Thus the budgets for transformation get consumed quickly and then the questions about “what results you have achieved from running the transformation?” get asked – eventually budgets getting pulled off or clipped.

Designing Transformation Sprints

A good to way to conqueror this can be to design the transformation as a series of “transformation-sprints” which together deliver the large enterprise “transformation-vision”. Each sprint individually delivers at least a small, tangible piece of that large goal. Success is always sweet. When success is achieved in incremental manner, the teams get confident and also the leadership develops confidence that the money spent is put to good use. My experience is that these sprints should not be too short. They should be one month long. Generally one month is a good timeframe for getting tangible results.

Use Scrum Events and Artifacts for Inspecting and Adapting the Transformation

I suggest that these sprints follow the scrum events and artifacts. It allows the team to collaborate in a structured manner.

• A Product Backlog with improvement items in it which are ordered makes a lot of sense. It is usually a good idea to use Themes or Attributes since the teams working on these items are many.
• A Sprint Backlog is a short-term plan which has to be achieved during the month. Each team should decide its own Sprint Goal and should have a own Sprint Backlog
• Sprint Planning for one month should be used as described by LeSS framework – i.e. divide Sprint Planning into “Sprint Planning 1” and “Sprint Planning 2”. Sprint Planning 1 is an overall Sprint Planning. Sprint Planning 2 should be for individual teams to plan their own Sprints.
• Daily Scrum for individual teams to sync for 10-15 minutes everyday makes a lot of sense.
• Sprint Review is the most important event which presents the results achieved to the stakeholders. Stakeholders who are spending money for a initiative would be keen to know how their money is being spent.
• Sprint Retrospective to improve the next month makes a lot of sense again since the transformation itself is an improvement initiative. My advice is that one should do 2 levels of retrospective – one internally and one externally. 

The post Planning Agile Transformation Sprints appeared first on World Of Agile.

In my experience, Agile Transformation can be run as any other Scrum implementation. Thus creating an Improvement Backlog which is an ordered list of everything that needs to be done during the transformation can be created.

Some items which need to be considered

Each Item must have a tangible Business Value

Generally the leadership teams are used to running such initiatives as long term plan-driven initiatives. Thus what ends up happening is that, the list of improvement items becomes a planned list of activities rather than having some tangible business value. The most important thing in a transformation exercise is to define the tangible business value with each item so that everyone knows “Why are we doing this item”. It helps to consciously call out the business value attached with each item. Over time this becomes a habit but it needs attention and focus initially while the team is getting used agile way of working

Ensuring that the Items are small

When the leadership teams are used to running big-bang transformation items, each item spans across multiple months. In my opinion, each item should be small such that a quantifiable value is achieved within one month time.

Acceptance Criteria should be defined

Measurable Acceptance criteria defines when an item is successful. This helps the implementation team get confidence about the implementation being done is resulting in tangible business value. In large transformations, there always will be “Skeptical” stakeholders and “Change Resistant” stakeholders. This way of working helps silence such stakeholders. 

Consider Creating Themes

For a recent transformation I was a part of some of the initial items in the backlog were 

• Increase Scrum awareness, 
• Create a supporting organization structure that enables scrum and Increase automation
• Training
• Spreading awareness of tools
• Re-arranging of the team-space (working area) of teams

Each of these items needed to be implemented by completely different teams. Hence, managing the backlog was becoming a difficult task and we ended up creating a “sort-of” sub backlog for each of the items in the parent backlog. Another way of thinking is that we create Themes in the product backlog which clearly identify the set of items to be undertaken by each team.

The post Running an Agile Transformation with an Improvement Backlog appeared first on World Of Agile.

A lot of organizations now a days have a plan to move to agile. For which they hire “consultants” , do a “analysis” and come up with a detailed, prescriptive plan that they intend to track meticulously to completion. This in itself is “waterfall” way of work.…

In my experience as Scrum Master as well as an Agile coach, a plan dictated approach usually does not work for to transform an organization to agile ways of working. This in no way means that agile transformation does not need planning, indeed it does but the plan needs to be flexible and driven by value delivered. In short, its best to drive an agile transformation in an agile manner.

Key aspects to drive the agile transformation in this way are

Have the transformation driven by business value

Many organizations are starting the transformations, just to get on “agile ” wave. They have no idea why they want to be agile or what they will gain from being agile. It is important to have a clear idea about what business objectives will be achieved by being agile. With out clear business objective – transformations will fail.

Plan Short “Time-boxes” 

Often the transition to Agile are like plans which are detailed, prescriptive and long term. Many time they do not give a tangible value that gets delivered sooner rather than later . This in itself contradicts the agile principle of ” Early and Continuous Delivery  ” I have found it very helpful to divide the ultimate transformation goal in smaller , more immediately achievable sprint goals that can be demonstrated to stakeholders. This also helps to build consensus and create a positive vibe about the whole initiative

Get together an Agile Team

Like any other project, transforming to Agile way of working in an organizational is a complex and challenging work. It needs all the 3 important roles of a scrum team. A experienced scrum master . A product owner – who can articulate the value and represent it in the backlog. Lastly, we need a development team that actually implements the backlog items.

Build a tentative Product Backlog

While its easily said to have short sprints with sprint goals that are achievable and can be demonstrated, its another story to actually identify those goals. It is important to build a prioritized and refined backlog to achieve the business value that is desired. This product backlog refinement is ongoing activity and usually a good scrum master with facilitation skills will be able to achieve this goal .

Some of the following blog posts may help with further understanding of this topic

• Preparing Agile Transformation Backlog
• Running Agile Transformation Sprints
• Defining Tangible Transformation Value
• Agile Transformation Challenges
• Right Pilot for Agile Implementation
• One Team Culture
• Adjusting Master contracts to suit agile
• Agile Contracts

The post Agile Transformation in An Agile Manner appeared first on World Of Agile.