In a Scrum or Agile team is it advisable for a Product Owner to be involved in more than one product? Is it good to have a Product Owner for the Enterprise System and "sub" Product Owners for the components of that system? i.e. In a Retailer would you have a PO for the enterprise system that drives "sub" PO's for say Retail, Supply Chain and Manufacturing?
Be interested in how others deal with Scrum teams in an enterprise environment with many stakeholders in functional silos.
A product owner can be in this role for multiple products, depending on their size. On the other side, you can have multiple product owners for sub components of a larger enterprise application. Then you have a "Chief Product Owner".
It's perfectly valid and advisable.
All those concepts are detailed in the book Agile Product Management With Scrum: Creating Products That Customers Love written by Roman Pichler.
I've seen hi speechs and talk to him many times at Scrum Gatherings. His specialization is Product Owners.
I've been a ScrumMaster in a similar situation. You can have "sub" product owners or "joint" product owners for sub systems of your development effort; in an enterprise this is pretty common. They in essence become a "Product Owner Team", which may also include business analysts.
However you should have a designated 'lead' for this product owner team; someone who can settle differences and establish overall priorities for the backlog This person should make sure that the needs of all the other product owners are met. In practice, this has usually been the project manager.
An alternate approach is seperating the sub-projects into seperate scrum teams, and then have a 'scrum of scrums'; but I don't think that will work for a single development project, as that will create more difficult information flow between the teams. Unless each sub project can function independently of each other, I'd suggest the first approach.
In a Scrum or Agile team is it advisable for a Product Owner to be involved in more than one product?
First of all you have to understand that you won't have an objective answer to this in Scrum. You will have to inspect and adapt. Nowhere in the Scrum Guide (written by the inventors of Scrum) is it mentioned that a PO should not handle more than 2 products but they do mention that for the PO to succeed (s)he has to take full responsibility of the Product, and the organisation has to respect the POs decision.The PO is a "pig" of the Product Backlog, be it for 1 or 2 or more products, if the PO and the Stakeholders can handle this I would say try it, and inspect and adapt. And there are various factors also like how complex the products are, and how speacialised the Product Owner is in them and how much bandwidth the PO has to do the PO duties for more than one product. Please take all of them into consideration before trying it.
Is it good to have a Product Owner for the Enterprise System and "sub" Product Owners for the components of that system? i.e. In a Retailer would you have a PO for the enterprise system that drives "sub" PO's for say Retail, Supply Chain and Manufacturing?
Again you will have to try it in your organisation to know if it is "good". Just follow the right Scrum guidelines when appointing the POs or sub POs. I tried it in my organisation and it worked wonders! We had a Chief PO, and several other POs who you may call sub POs but I prefer keeping everyone on the same level to avoid command and control behavior which when misused can ruin a project. The Chief POs job would be to make sure the POs are successfull in what they do, and also help the POs out when needed. Also appointing POs could be done by Chief PO along with a chief SM or SM. If I may digress a little, the same structure was followed with SMs. The Chief SMs job would be to help the SMs succeed at doing their job, for example if an SM cannot resolve an impediment he or she could have the Chief SM come in to the picture to help resolve it.
Be interested in how others deal with Scrum teams in an enterprise environment with many stakeholders in functional silos.
Like I already mentioned above. We had a chief PO, and several other POs in our enterprise environment. There was also a steering committee which included stakeholders. Each PO had their own product backlog to manage. We had 2 week Sprints. Twice a month we had a meeting called the 'Steering Committee Meeting" where all stakeholders and Chief PO and POs met, and steered the Enterprise product in the right direction, and the each of the POs translated the work in Scrum terms (potentially shippable user stories) for each of their products, the Chief PO had a crucial role of educating and protecting the POs from the Stakeholders and members who had little knowledge of the Scrum Framework. They protected the POs from being hijacked. Each PO had an own Scrum Team with a SM and team members. I would suggest have the chief PO be an Agile coach with a good hold high up in the organisation. Also have the POs collocated, it helps especially in resolving cross team dependencies and issues.
Note: One thing that had not worked for us was 2 POs for one team with one product backlog, there were just too many conflicts between the POs!
Hope this helps.
In a Scrum or Agile team is it advisable for a Product Owner to be involved in more than one product?
As long as the PO is able to work on the Product Backlog(s) to get a set of prioritized Product Backlog Items before each Sprints, is maximizing the ROI, and is available for the Team(s) during the Sprint (in other words, as long as the PO is doing his job), it should be ok. If he is not, major impediments will be raised quickly.
Is it good to have a Product Owner for the Enterprise System and "sub" Product Owners for the components of that system?
This is actually a typical pattern when using Scrum of Scrums to scale Scrum. And scaling Scrum to a entire company is definitely doable (Scrum has been designed for infinite scalability --Jeff Sutherland), and Scrum has already been used with huge teams (500+ people).
But I would certainly not try to scale Scrum to a whole company directly, there are steps to follow for Enterprise wide Scrum/Agile deployment and not doing so would be crazy (a good recipe for failure).
Rally has IMO awesome presentations, white papers and blog posts on this topic (well, they aren't the only one but I enjoyed reading their material). I warmly suggest to have a look:
I'm pretty sure you'll get a better picture after reading some of these resources. But I'm not saying this is easy.