Two Masters with a Single Wringable Neck

The concept of two Product Owners is something that has perplexed me for a while. Pretty much ever since I started Scrum and Agile there always seemed to be more than one accountable person for a project. And really, in a large company, that is probably right. Even outside of the Scrum I nearly always have at least two bosses. If the two bosses are aligned in every way, then great - but maybe a bit redundant - if not then trouble. And trouble is what I often find myself in.

But, I'm not alone. In fact, this is an age old problem. The bible, yep, the bible says:

“No one can serve two masters. Either you will hate the one and love the other, or you will be devoted to the one and despise the other. You cannot serve both God and money." (Matthew 6:24)

Nor can you serve product manager and business development manager, it seems :)

That is, at least what I thought...

I started researching what others thought about two Product Owners. The Scrum White Robes said, of course, "No way - you can only have one Product Manager otherwise it's not Scrum". Those who live closer to reality had some interesting and sometimes novel ideas.

Mona Singh, of Channel Advisor Corporation, back in 2008 had a similar problem - and wrote a paper on her solution. The paper, which was presented at Agile '08 and published by IEEE, is called "U-Scrum: An Agile Methodology for Promoting Usability" (http://www.mendeley.com/catalog/u-scrum-agile-methodology-promoting-usability/#). Her team had a problem while developing a software-as-a-service application, which relied heavily on both business functionality and user experience. She found that the Product Owner was focused on getting functionality completed; Her team was focused on "working software" - and doing Scrum right(!), but that meant that they weren't able to focus on things like a strong usability framework. The solution was to have two Product owners: 1. whose focus was on the product plan (or roadmap), and the backlog (or business functionality). The second, had a focus on usability and was guided by a user experience vision (UE Vision). This UE Vision reflected "the intuition that architecture must ultimately serve the needs of users". The sprint backlog was made up of items from both Product Owners given equal weighting so that both could be focused on during a sprint.

Sounds good, but I'm not sure that all this can't be fixed by a good "definition of done" that says something must meet a usability guide or be tested by the usability team, etc. But Singh's ideas about two Product Owners working cooperatively are interesting.

Roman Pichler has a great way of describing how to work with multiple Product Owners, he calls the "Highlander Principal" (http://www.romanpichler.com/blog/roles/the-single-product-owner/), whereby "there can only be one". I like the story Pichler has told and gives some good advice. But, design by commitee is not a good thing either- the old saying "a camel is a horse designed by committee" rings true too often.

Kevan Hall (http://www.huffingtonpost.com/kevan-hall/managing-multiple-bosses_b_2485308.html) suggests that if you have two bosses "rather than being a 'matrix victim', he recommends becoming a 'matrix manager.' You might think that having two bosses would mean more leadership and support, but often it means less. When we have multiple bosses we need to take more ownership for our own goals and roles, and the good news is that this can lead to much more satisfying jobs". The same could also be said for Scrum Masters to ensure that, that old favourite, communication is flowing freely and often - the Scrum Master after all is more than just a problem solver, it's a leadership and supporting role.

"Product Owner Must Die", by Saeed Khan (http://onproductmanagement.net/2011/05/16/the-scrum-title-product-owner-must-die/) says - "bring it on - give me more managers". He says that the Product Owner has two many roles to fulfil already, so split them up. The Product Owner should only focus on the need for "ongoing backlog prioritization, the necessary interaction with the Development team so they can make progress on the backlog and stay aligned with the needs of the business. Everything else, from P&L to budgets, to roadmap and vision are irrelevant" someone else's problem.

Self confessed "jerk", Tom Perry (http://agiletools.wordpress.com/2011/11/01/on-product-ownership/) has to deal with Product Owners who "don’t show up for the stand-ups, when they come to the stand-up meeting they don’t bring any stories and instead simply review whatever the team has brought to them – and then leave early because they have more important things to do." From what I've seen, maybe they do, maybe that's why they were put into the role - because they are good at what they know, therefore they are needed by the business. Maybe that's why we need more than one Product Owner?

Joseph Flahiff (http://agilediary.wordpress.com/2009/02/21/one-product-owner-only-or-more-than-one/) asks "How can one person be so powerful as to be responsible for the overall success of the product?" and has some interesting arguments to back it up, none more powerful than - Agile is cooperative by nature, why have one "single wringable neck" - aren't we all in this together?

Once again no answer just more questions :)