Skip to main content

Product Owner as Nexus Scrum Master

Last post 08:34 am March 21, 2016 by Ian Mitchell
4 replies
06:59 am March 18, 2016

It is not recommended that the Product Owner and Scrum Master be the same person on a Scrum Team. Although this is not strictly forbidden, the potential for a conflict of interest is significant.

To what extent does this potential for conflict of interest remain significant in a Nexus Integration Team? At the level of product integration, does it become more reasonable (i.e. less unreasonable) for the Product Owner to also be the Nexus Scrum Master? Assume that the PO has the requisite Nexus SM skills and understands how the Nexus framework ought to be enacted.


02:02 pm March 18, 2016

Ian,

My view is - As the scale increases, the potential for vested interests, less transparency, demand for managing additional overhead increases. Given that, while we can't recommend the concentration of responsibilities at lower scale, we certainly can't go for it as the scale goes up.

Though there is no direct reference to this in scrum guide, I remember Ken Schwaber, Roman Pichler, and few more writing the "NO COMMON ROLE PLAY" in certain terms elsewhere.

Reproducing the reasons from my book below, to explain about the potential of concentration of responsibilities and why it could lead anti-self-org:

Considering the primary job of each of these roles - a Product Owner wants to maximize/optimize the value of Development Team’s work. It is possible for them to push for “more work” while compromising on definition of "Done” or technical quality requirements. They may also overlook the Development Team’s empowerment of deciding for themselves how much work they can select for a Sprint.

In such conflicting situations, a Scrum Master teaches both the Product Owner and the Development Team about their empowerment and balances. So, we can see that there should be situations involving conflict of interest if one person plays both roles. .
The issue is not about who will play what role. By doing any of that, are we going to have Scrum or not - is the question.

Think about the fundamentals of Scrum. It is risk reduction framework for building complex products. Scrum team is not just self-sufficient. It is also built in instability with respect to responsibilities. The risks and subjectivities associated with traditional one man centric Project, are mitigated by distributing the responsibilities between three roles. Now, what happens if you bring Scrum Master and Product Owner under single hat? You can sense the concentration of responsibilities. It increases risk and reduce self-org. Will it be Scrum?


05:35 am March 20, 2016

Here is a scenario which I hope may illustrate the point I am raising.

Suppose company X provides a software product...a suite of office applications. The suite consists of XWriter, XSheet, and XPresenter. Each application in the suite can be sold and used independently, but they are developed and released as a suite. They share common versioning, a common API and object architecture, and there is a common backbone of components.

Each application is therefore a separate product, but they are integrated into a composite product increment which is the entire suite.

In this type of composite-product situation, a Nexus Integration Team is tasked with assuring the integration of component products. Since each component product is discrete and usable in its own right, the problem of integration is one of maximising the value of how delivered products are used.

To the extent allowed by this example, the potential for conflict of interest between Product Owner and Scrum Master roles might possibly attenuate at scale. At the very least, assumptions regarding what the conflict amounts to in a Nexus may deserve some reconsideration.


06:57 am March 21, 2016

Ok. I get that. Assuming that the potential conflict goes down - remember this is still an assumption and the famous saying in under siege II 'assumption is mother of all ***' - the nexus still needs to inspect and adapt this case.
Interestingly, the statement in nexus guide is slightly open about the composition too "Composition of the Nexus Integration Team may change over time to reflect the current needs of a Nexus"

Having said that, I see that the bandwidth of PO is going to be more demanding in scale and similar is the case for Nexus SM due to the problems of new order in scale and his/her responsibility to coach the teams navigate them. Curious to know why you want to try this and did you get a chance on the ground to see any insights


08:34 am March 21, 2016

> Curious to know why you want to try this and did you get a chance on the ground to see any insights

It's the other way around. I have preferred to avoid vesting the Nexus PO and SM roles in the same person. A Nexus Integration Team is still a Scrum Team, and the experience of Scrum Teams is that there will be an unreasonable conflict of interest.

However, this amounts to received wisdom, and the evidence I am seeing is that the potential for a conflict of interest attenuates (or changes significantly) at scale. Specifically, if there is a Nexus Scrum Master who is *not* the PO, I have observed that the SM will be heavily dependent upon using the PO's skills and influence to resolve integration problems. Essentially, those problems are less likely to be technical and more likely to be a matter of product value and configuration. The SM is very close to being a bottleneck if he or she is another person. However, I don't have enough data yet to assert a pattern or anti-pattern.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.