Product Owners or Product Ownership

Last post we explored the idea that teams are the elemental building blocks of agile organizations. We talked about how teams need steady inputs if we are going to expect steady outputs. Towards the end we concluded that the Product Owner in Scrum is that single person responsible for making sure the team has what it needs to deliver working software.

In most organizations, the Product Owner is pretty simply acting as a buffer between the team and the business. This is a nice clean solution for the team... but what about the Product Owner? Did we actually solve the problem or just transfer ownership?

If our cloud of stakeholders can't make up their mind about what they want... if there is no vision and they can't give clear direction to the Product Owner... the team will come to a standstill. The Product Owner will be unable to keep the backlog full of groomed features. The team will be unable to deliver working software.

What I am suggesting here is that we don't really so much need Product Owners... what we need is Product Ownership. We need a business that can make up its mind about what it wants to build and then translate strategic direction into products, projects, and ultimately backlog items our teams can build.

Right now teams are struggling. The are struggling not so much becuase they can't figure out how to write code... do continuous integration... test... or conduct a retrospective. They are failing at agile because we have pushed the alignment problem outside the team to a business that is not prepared to adequately provide a solution.

Solving this problem is going to be integral to any discussion of scaling agile.

Decisions, Decisions, Decisions

Deciding between feature teams or component teams is the first design decision you'll make as you build out your organization. Deciding on the right teams to build those features or components is the second.

Without a firm commitment to establish teams, decide what they are going to work on, and to coordinate their backlog... making sure they are always working on the highest value stuff ... your agile transformation is going to struggle. These decisions are foundational to everything else we are going to talk about.

From here out our discussion is going to revolve around figuring out how to give our teams the right stuff to work on.... coordinate their activities... do it in a way that best delivers on our organizations goals.... while minimizing the cost of context and coordination.

Comments

[Hadi Curtay]

Wonderful article. Really looking forward to the articles on how to give our teams right stuff to work on. I think this is a key area which can increase our pace of work.

[David]

Hi Mike,

I think if the business gets too close to the actual details of product backlogs, assigning items etc, it could cause issues. Surely having the buffer of the Product Owner to sift through the information and pass on the relevant details is a time saver and causes less confusion. Then the project manager or scrum master can decide which backlogs to add tasks to etc

Regards,
David
http://www.jacksguides.com