Are the Product Owner and ScrumMaster’s Interests Opposed?

The Chief Engineer role in the Toyota Product Development System combines parts of the Product Owner, ScrumMaster, and senior technical team member roles from Scrum. In addition to leading the technical design of a new product and facilitating the work of the other engineers, the CE must deeply understand and care about what the customer values—he has ultimate responsibility for delivering value to the customer and for the resulting commercial success or failure of the product.

CEs have gone to amazing lengths to gain that deep understanding of the customer’s needs.

For example:

While developing Toyota’s successful 2003 Sienna, the Sienna CE drove his team in Toyota’s previous minivan model more than 50,000 miles across North America through every part of Canada, the United States, and Mexico. The CE experienced a visceral lesson in what is important to the North American minivan driver and discovered in every locale new opportunities for improving the current product. As a result, the Sienna was made big enough to hold full sheets of plywood while the turning radius was tightened, more cupholders were added, and cross-wind stability was enhanced, among many other improvements that resulted from this experience.

(From The Toyota Product Development System by James M. Morgan and Jeffrey K. Liker, p. 30)

If you’ve followed recent discussions on the scrumdevelopment group, you’ve seen multiple threads over the last couple months that discussed how the interests of the team, SM, and PO are intrinsically in conflict and that acting as both PO and SM requires a kind of useful schizophrenia.

I have to wonder: Toyota is one of the best product development organizations in the world. Are Toyota’s CEs a special breed, immune to the conflicts of software teams? Do the rest of us need distinct roles to balance our selfish interests?

At the very least, if we find that the interests of our POs, SMs, and teams seem to be fundamentally in conflict, we should ask why. Shouldn’t we all have the same goal: Producing valuable software now and in the future? Perhaps we should consider how to align around that goal rather than how to balance the interests of roles centered on lesser goals in the hope that we achieve the true goal as a kind of dialectical byproduct.

It’s one thing to say that the PO and SM roles ought not be combined because each is so demanding that it requires a person’s full time attention. But it’s quite another to say that the roles are fundamentally locked in a conflict too intense to be handled by a single person, and that better software results from that conflict.