Product Owner as Nexus Scrum Master

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?

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.

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

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