The PO Role — some controversy

October 9, 2017

Here is a quote:

This is far different from the Product Owner role in Scrum, which directs the PO to simply hand the development team a prioritized backlog of work to do.

This quote is from a post on LinkedIn, and a bunch of senior agile people are fervently discussing it, on at least two sides. I won’t define what the initial “this” is referring to, but clearly the speaker feels that his “this” is better than the “simply” stuff that he ascribes to Scrum.

Most of the talkers are smart, but I worry that we have much heat (for not especially good reasons) and not enough light.

So, an attempt here (below) at offering one candle (rather than to curse the darkness, is the expression). But a brief candle, Macbeth. So, pardon that we do not have space and time to flesh out these comments.

Scrum is a game.

That is, Scrum is a team sport. Exactly how to play each position is left to the Team to decide (and maybe the org). Use your ideas, and play it, to some degree your way, and see how that works for you.

We do recommend a decent experiment actually playing by all the rules (I mean, do try out the real game, right?). Using all the rules is not complex, but apparently hard.

In the present case (PO), beware of any “just” statements. Scrum assumes we are real people, and real people are not “just” anything. They are hugely complex and work together as a Team. And the Team works also with the rest of the Org and (likely) with people outside the Org of course.

Minimize talk of dysfunctions

The speaker of the quote, when questioned, allowed that Scrum (eg, the Scrum Guide or any book by Sutherland/Schwaber) does not define the role just that way. He stated that, nonetheless, he sees this dysfunction commonly.

And this is basically true, but irrelevant. That beginners (and others) say they are doing “Scrum” but do not do real Scrum should surprise no one at this point. All 6 year olds do not really play baseball at first, but rather some ugly thing that they call “baseball” — it does not say much about Major League Baseball.

***

Now, let me define the PO role in Scrum quickly with a few ideas. (Some will disagree.) (For now, envision a PO of one Team of 7 people working alone on one product.)

Final prioritizer

It is key in Scrum that someone prioritize the next PBI (or user story), and also further out on the PBL too. More generally, the different people who have relevant information tend not to agree on the order, so someone (the PO) must listen, and then be decisive quickly, under uncertainty. A saying I link to Ken Schwaber: “No decision is almost always the worst decision.”

Inspirer

The PO must carry the vision and articulate the vision of the work (the product). And inspire the Team and others with that vision. I think most POs do not consider this part of the PO job. It is. Motivation of knowledge workers matters. Inspiring 6 other people is not easy, and you cannot “make” them be inspired. But you can articulate the vision so that each could be inspired.

In this category we should add “product strategist”. At least for his/her Team. (Depending on the situation, the PO may have to work on this with a “Product Manager” or some similar person.) That is, using Lean Start-up ideas or any other ideas that might be good (in your situation), convert these ideas of how to achieve success into a concrete approach that can be taken. (You might guess that I like Lean Start-up, but Scrum, as a bare framework, does not insist that a PO must use the Lean Start-up approach.)

Fast answerer of questions

The PO must collaborate with the Team daily. (Ok, not exactly every day IRL, but as close as is humanly possible.) The rubber meets the road in answering questions (that always come up) quickly. 10 seconds would be really nice.

If life could be divided easily into business questions or technology questions (it cannot), then the PO would only be answering business questions. But, as it turns out, about any interesting question is a trade-off between business and technology issues in our domain of technology innovation.

BTW, the PO does not always have the “answer”, but must pull the answer from … the right people. Hard.

Provider of an Enabling Spec

By this we mean Jeff Sutherland’s idea of Enabling Spec. That is, just enough, just in time information before the sprint starts for each of the (Joe says 8+) stories. And the information is in their heads (and maybe on paper some, maybe in a picture(s) of some sort). And the Implementers feel that they have what they need to be successful — they don’t have the classic “unclear requirements” when the sprint starts.

The PO does not normally do this alone. He/she must pull from … the right people… to pull this information together.

Leader of product backlog refinement

The Scrum Guide does not define PBL refinement very much, but the PO “owns” the quality of the product backlog and leads the refinement. In my opinion, this means both the short-term (eg, the next 8+ stories) and the long-term (eg, what will be in the next MVP to be released). [Yes, I am not assuming CD for now. If CD, then I would express this a different way.]

***

Even having said that (and the Scrum Guide says less), the PO role can be played many ways, and supplemented by other pigs or chickens.

At the end of the day, the Team wins or loses together. The Team must figure out, in their specific situation, how to win or how to win bigger.

Or, that’s what Scrum says. The people always have the option of doing other things, such as waterfall, or another agile method, or something that is not even a “team discipline”, or whatever.

Now we come to an awkward pause. How much does Scrum define the 3 roles and how much does Scrum leave them undefined? I think the answer is that each of the 3 roles is, at a high level, defined (PO, SM, Implementer role), but also each is very loosely defined and there is a lot of room for flexibility. On purpose.

For an immature team, this looseness may have some negative aspects. (They really need a good coach.) Joe Schmoe with no coach is unlikely to self-organize into Tom Brady. Quickly.

For a mature team working in a new challenging area, this relative lack of definition is not a bug at all, but only a feature. They need a few constraints, but not many.

***

Hope my comments at least help you think, and then act more effectively. And get better results (including more fun).