Another Kind of Overloaded Product Owner

We all know that basic Scrum looks like this:

I like to refer to this kind of Scrum as the “five people in a garage” kisnd of Scrum. In this metaphor, imagine the Team is all together in a garage, the Stakeholders live next door, and the Product Owner is talking to them over the fence while he/she is standing in the door to the garage.

Basically, the Product Owner does two things:

• Spends half’ her time working with the Stakeholders, producing and prioritizing the Product’s Backlog in order to maximize the value of the Product.
• Spends half‘ her time with the Team, refining the Team’s Backlog in order to maximize the value of the work of the Team.

Not all Scrum Teams are like this

In a previous blog I showed that a Scrum Team whose Client is in Washington DC, while the Team is in Bangalore, might require two Product Owners. One of the Product Owners would be with the Client in Washington and the other Product Owner would be with the Team in Bangalore. Because of the distance and time differences, it may be impossible for a single Product Owner to do his/her due diligence to both the Client and the Team.

In this blog, I’m going to describe another kind of ‘Overloaded’ Product Owner –– one where the Product Owner is trying to manage multiple Scrum Teams. Here’s a picture… the Product Owner is working with the Stakeholder and serving as each Team’s Product Owner.

This is what is going on:

• The Product Owner is spending half her time working with Stakeholders, producing and prioritizing the Product’s Backlog in order to maximize the value of the Product.
• The Product Owner is spending half her time with each Team, refining the Team’s Backlog in order to maximize the value of the work of the Team.

This looks like it takes two people to do this work, so either the work is real easy, or the Product Owner will be unable to do her due diligence to both her Stakeholders and her Teams. Just to be safe, I’ll assume the latter — this Product Owner is overloaded.

So, what do we do about this?

1.  Well, each Team needs a Product Owner, so appoint a member of each Team to also serve as the Team’s Product Owner — to be accountable for refining the Team’s Backlog in order to maximize the value of the work of the Team.
2. Take each of these Team Product Owners and have them work with the original Product Owner on a ‘management’ Scrum Team whose purposes are:

• To keep everybody in sync.
• To distribute the Backlog to the Teams to keep everything in balance.
  • Note that there might be other people on this team, to be used as shared Subject Matter Experts.

Have the original Product Owner work with the Stakeholders to produce and prioritize the Product’s Backlog in order to maximize the value of the Product, and act as a Subject Matter Expert for each of the Teams on an as-needed basis.

The following picture shows this relationship. In order to remove the confusion of multiple Product Owners, I have called the Team’s Product Owners Team Leaders, and I have called the original Product Owner the Business Owner.

So, what does this do for us?

1.  The main thing is that it distributes the Product Ownership load — none of the Product Owners are overloaded.
   • Each Team Leader is spending half her time with her Team and half her time with the Management Team, and
   • The Business Owner is spending half her time with the Stakeholders, and half her time with the Management Team.
2. There is a Team (the Management Team) dedicated to the overall problem. Because of this Team’s Daily Scrums:
   • The Team Leaders are kept in sync, and this allows everyone to be kept in sync.
   • Each Team’s Impediments can be raised to the next level quickly, which is good for everybody.
3. There is a home for Subject Matter Experts to live, so that they may be shared by the Teams.

This solution is an example of Scaling Scrum with Scrum™, and is an instance of the Distribution Team Pattern, which you can find here.

Once again, we see that Product Ownership is an interesting thing, and shows that we often need to do more than just basic Scrum to solve problems. Some people won’t like this solution, and would say “that’s not Scrum” — but they’d be wrong.

As I have said before, making trade-offs like these are required by Scrum as part of “inspecting and adapting” of the process.