Wednesday, August 29, 2007

A Product Owner for Every Team

At Agile 2007, I went to a session called Product Ownership. I was interested in any session of product owners because we have hit issues with having one product owner for a large team and have experimented with having embedded product owners in multiple teams. I was hoping to hear stories from other teams who have addressed the same problem.

The session consisted of three good presentations, but one in particular hit the mark in addressing the multiple product owner solution. The presentation was called "Effective product ownership within a multi-component project" by Mike Lowery and Marcus Evans.

The presentation covered a project being developed at the BBC which delivers television shows across the internet. The project is large. Nine Scrum teams have been created to work on it.

The team immediately ran into problems having one product owner (quotes from the proceedings in italics):

  • The Product Owner was so busy that he was not available to make timely decisions.
  • Even though the Product Owner was manically busy, he never actively empowered the teams to make their own decisions. This lead to an interesting shift in development. Some teams were frozen by this and development slowed to a crawl. Other teams did what they felt like and moved the development forward only to have work scrapped when the rumors stopped and the Product Owner finally gave direction.
  • Product backlogs were not prioritized so teams started to build items in the order that they preferred and moved unattractive items to the bottom of their product backlog...
  • Whenever any attempts were made to prioritize the product backlogs, the Product Owner struggled because the items on the list were only understandable by the teams who wrote them.
  • The number of scope meetings rose to fever pitch, as what was in and out of scope was never clear and the Product Owner was never available.

The team went through a few changes to the product owner role, creating two product owners and eventually moving to having each team appoint an embedded product owner (PO as Pig). The benefits were:

  • Clear product ownership.
  • Definite project direction.
  • Questions were answered quickly.
  • Delivery teams had planned thought out product backlogs.
  • Work picked up pace and we were back to delivering new functionality each iteration.
  • The in-team Product Owners became subject matter experts.
  • Each team put itself into a specialist silo.
  • Team direction was not always business direction.
  • Product backlog items fell through the gaps between teams.

The first concern raised about this (and we raised it ourselves) was how to avoid silos for each team and a lack of vision for the product as a whole. This is addressed by maintaining the central, or core, team with a project product owner.

The Product Owner from the central team does not give direction on individual features and rather is there to ensure that the overall business direction of the project is maintained. They also ensure that things do not fall through the perceived cracks between the teams, and that dependencies and impacts are captured mapped and coordinated. The in-team Product Owners were retained to act as product specialists more than pure Product Owners who set priorities.

The role of the core product owner is to identify the epic (large) stories and their priorities for the project.

This has worked well for the BBC and has worked well for us. Communication among the product owners is important and deserves a regular stand up meeting to address impediments to the vision of the game.

No comments: