In the Team

Context

The team has a product owner. She sits with the team, attends the standups, writes the user stories, and manages the backlog. She is good at her job, but she is not really making product decisions. She is translating decisions made by a business stakeholder who sits outside the team and controls the budget. The team builds what she tells them to build, being the proxy for the business which tells her to tell them. She does not really have the mandate to decide much. When the team raises a concern about direction, it goes to the PO, who raises it with the business, who considers it and comes back three weeks later with a modified brief. The team is a feature factory. Everyone knows it. Nobody knows what to do about it.

OST explains

The product owner role, as conceived in Scrum, places a single person in charge of deciding what the team builds. That person is formally part of the team but functionally a conduit for management, the ordering-supplier divide between business and IT given a new job title. This is DP1: responsibility for goal-setting sits above the work, even if it sits only one step above rather than many. A self-managing group in DP2 owns its whole task, not just how the work is done, but what work is done and why. That means the team has a genuine relationship with the customer and the business context, not a mediated one through a proxy. Marty Cagan’s distinction between feature teams and empowered product teams maps almost exactly onto DP1 and DP2: in the former, the team is handed a solution to build, in the latter, it is given a problem to solve.¹ The difference is not about process or methodology. It is about whether goal-setting lives inside or outside the group. Until that changes, the product owner is not empowering the team; she is the most visible evidence that it is not empowered.