It’s all about the Raspberry Jam

“The Law of Raspberry Jam: the wider any culture is spread, the thinner it gets.” — Alvin Toffler

I recently delivered a series of Product Owner training courses for a large (massive, really) multinational corporation. The company has an Agile rollout strategy and a reasonable amount of tactical planning in place for making it happen. During the course of the training, one of the more interesting discussions that arose revolved around how many teams each Product Owner would serve. The Scrum answer is, of course, one and only one Product Owner per Scrum team. There are a variety of reasons for this one-to-one relationship between Product Owner and team, a few of which are:

  • The Product Owner is a pig, a committed member of the team who shares in the ups and downs of the team’s experience
  • The Product Owner is the sole voice of the customer, the single source of business information on the team
  • The Product Owner continuously prioritizes the Product Backlog, ensuring that the team always pulls the highest-priority work into each Sprint
  • The Product Owner makes sure that the team never runs out of high-priority stories to work on
  • The Product Owner and team build a relationship of trust and mutual respect based on shared work toward a common goal

The plan at this company was to have each Product Owner serve five teams, which brings us to the Law of Raspberry Jam.

Toffler was talking about cultures, but the same is true of people and roles. Spreading a Product Owner over multiple teams inevitably thins that Product Owner’s commitment to each team. The thinning of commitment makes the building of trust and mutual respect much more difficult, perhaps rendering that vital connection impossible.

Then there is the issue of keeping the backlog prioritized, groomed, and ready for each team to pull the highest-priority stories into each Sprint. I worked with a team a few months ago (at a different client) that had outrun its Product Owner’s ability to keep the backlog stocked with appropriate stories. As that team’s velocity increased, the Product Owner simply could not keep up. Imagine that situation multiplied by five!

The one-Product-Owner-for-five-teams experiment has not gotten off the ground yet, but I am very interested to see how it goes. As I told the trainees, it might work. But then again, there was no data or other evidence to support that supposition out of the gate, whereas for the standard format of one Product Owner per team, there is a huge amount of data that demonstrate success.

All for now…