Define a new role: Users#35

One of the most common problems with Scrum is that the PO is unable to correctly explain the user space (Jobs, Journeys, Mental Models) to the rest of the team. Hence, teams build features and even whole products that add minimal or no value. This is partly because the PO is ‘too busy’ to perform this role, partly because users are almost never offered the opportunity to provide feedback to the team and partly because the PO does not correctly understand what value delivery actually means.

I believe you are touching on a common problem, but is this the best way to fix it?

Value delivery is highly situational and a broad topic. Do you think we can solve this big problem with that small clarification?

Imo, only way of solving it would be to make the prerequisites of the PO more clear, but since that is situational, it is difficult to make generic.

You’re right, this problem is fundamental and cannot be solved by such a small change.

But I thought I ‘sow the seed’ here anyway…

Keep in mind that Scrum (and Agile) were developed by engineers to help engineers organise their work. They are thus engineering-centric (which is why the UX people laugh at Scrum and Agile…) and do not correctly take into account the need to actively manage the exchange of value between the user space and the company space.

We are constantly ignoring this problem which is right there in plain sight every day: for instance, how many Scrum teams invite users to dial into their Sprint Review to provide feedback on features that have been in production for several months?

It hardly ever happens. This is so easy to fix, but teams seem incapable of taking action. What is the Scrum Master doing to fix this clear impediment? Usually nothing.

I personally think we are at the point where we need to rethink and reimagine how we go about developing software products. We even need to go back to basics and clearly define what we mean by a ‘product’, what we mean by ‘value’, what value delivery means and how you can measure it.

Each of these are very complex topics and I think that one of the problems we have is that these words are used by us all every day - but we do not have an agreed understanding of what they really mean.

I’m in the early stages of developing a completely different model - let me know if you’d like to share thinking or even get involved.

The Scrum Master should not make up for PO shortcomings in the discipline of Products Management or lack of time, the same is true for Engineers and technical expertise. What the SM should do is to point out to the team that it could be beneficial eg to bring in users to reviews or refinement sessions, and question the definition of value (what does it mean, who defines it, what are the intended outcomes) so that people can get to those conclusions themselves. I don’t think the SG should prescribe any of this.

A good product manager will understand their market segment and also profile their customers and/or users. This is a product management 101 concept; a lot more to it than my short comment.

The scrum guide says “The Product Owner may represent the needs of many stakeholders in the Product Backlog”

This is simply a failure of a PO to do this. Scrum will call for this to be made transparent and then to help the product improve it. The common trend is not to have the right person take on the accountability. Putting a person in a PO accountability that has no product management understanding is just silly, it will not end well. No wording change will fix this. Nor will it fix the problem of the PO not having time.

I continue to argue that the stakeholder is the best description for a non prescriptive framework as Scrum. I am happy with the current responsibilities of a stakeholder and therefore argue to make the stakeholder an accountability.

This is not an agile nor a scrum problem. The problem is that” the business “ need to organize. The PO than can take his role as conductor. Anyway the PO role is a very havy role that needs all the support from the company.
On the other hand the PO need not to know everything so he or she can invite a specialist to explain the scrum team what needs to be done. The PO needs to prioritize the backlog in discussion with all the other stakeholders.
The PO needs to take care that things are done and not necessary do it by him/her self