Multiple Product Owners for an Iteration

I’ve been working with clients making the transition to Agile. They are accustomed to a product manager “owning” a product, and negotiating for people to work on their product. Of course, that means begging, borrowing, stealing people from other projects and lots of multitasking. It also means that specific people have very specific knowledge of products or pieces of products, and it’s way scary for these product managers to consider allowing other people to work on their products.

These clients have organized their technical folks into teams to work together on projects, one at a time. There’s just one problem. They have more product managers than teams. What do the product managers, who are now product owners, do?

If they ask the teams to work concurrently on two products as if they are two teams, the teams aren’t really one team. If they ask people to slide work into an iteration, the people are multitasking. These folks need the structure of a timebox, which is why they considered and rejected the notion of a kanban board. But, they can rank all the work for an iteration jointly, and then ask the team to work on the stories in rank order.

Notice that they are keeping the idea of work flowing through a team. The two product owners are working together to rank the work for the iteration according to the project portfolio. At least one client is considering shortening their iterations so they can keep the team working on just one product for an iteration. They aren’t there yet.

The product owners are learning how to write smaller stories. The teams are learning how to put more people on a story to finish it faster. The product owners will need to collaborate and the leadership teams will need to keep reevaluating the project portfolio so the product owners can collaborate and provide one ranked backlog for the teams.

Transitioning to agile is difficult. Agile does make the issues transparent. It doesn’t make them easy to solve. At least they can see the problems.

There are plenty of ways for these folks to fail. But they are committed to creating teams who can work together. They are committed to no more multitasking. We’ll see how it goes.

If I didn’t know better, I would have guessed that someone from our organization wrote this post. 🙂 We’re going through a similar transition with the exact same issues here. Looking forward to further updates on the progress of this client!

I just recommended this post to someone asking this question on the scrumdevelopment yahoogroup. In addition, I make these two observations:

It’s best if the development team receives one stream of work. If there
are multiple projects/products represented by multiple product owners,
it’s best if they decide the business priorities between these projects
rather than leaving it up to the developers.

If they want to deliver functional software rather than create the
illusion of progress, then it’s best if they concentrate on one
project/product until they’ve accomplished a deliverable increment of
functionality before switching gears to another.