The buck stops with the product owner. There's three accountabilities in scrum:
- the product owner,
- the scrum master and
- developers.
I guess we would really want the scrum master and the developers to be doing some of that stakeholder engagement.
For example, during the sprint, I hope the developers have been introduced to the customers and end-users, so they actually refine what needs to be done. What was the thing you wanted again, you asked us six months ago and we're just starting to work on it now. What problem are you really trying to solve? Oh, that's what you try and do. That's not what we understood. So trying to get a common understanding of what's required.
I would expect developers to be talking to customers and end users and not the product owner kind of like being the proxy, kind of conduit between the developers and the customers. The product owner is ultimately on the hook for customers, end users, but also compliance stakeholders for example, maybe there's some suppliers that you're interacting with. Maybe there's other teams that we depend on and we need to interact with those. And there's the whole organization, of course, but the scrum master can help with a lot of this. For example, a scrum master is a change agent and should be able to work with other teams and maybe negotiate ways of working with those other teams.
They might not be working in a scrum fashion, but we can't just arrive saying we use a scrum, so you need to give us this tomorrow. They have their own lead times have their own ways of working. We need to be respectful of other people. And so the scrum master can interact with those people.
A decent scrum master should be able to negotiate on your behalf as well as the product owner in terms of how do we demonstrate compliance in this agile world? Can we see each other every month? And can I ask you two questions? Are you happy? Are you engaged? And if the answer to either of those two questions is no then maybe we need to talk more during the sprint.
But coming back to who's ultimately on the hook, it really is down on the product owner. And then I hope there would be a very good discussion within the team about what can the scrum master take away in terms of
responsibility there and what can the developers do? And how can we make sure that the product owner is effectively connected with the stakeholders that she needs to be connected to, to such an extent that we're kind of keeping an eye on the politics if you like in a positive way where the optics we might be doing very well as a scrum team, but if we're not being perceived to be doing well, that's important. So what are the expectations of these stakeholders? Do we need to help them embrace uncertainty?
Does the scrum master need to help them to understand uncertainty? And that sometimes we don't know when it will be done. So we need to use some regular forecasting to kind of give them some kind of information, still saying, we'll give you a better forecast next week. I think if there's one job I really want the product owner to be doing is to be really connecting properly with stakeholders.
I don't want them writing user stories. I don't want them writing product backlog items. I don't want them kind of stuck in with a team every single day, unless it's a really technical product or so on. The product owner has other things to do as well in terms of product management, commercial stuff, pricing, and so on, marketing.
And unless that stuff is all part of what the work is done on the scrum team product owner is going to be doing lots of other stuff. And so I hope there's some really healthy discussions within the scrum team about how do we deal with all these stakeholders and stakeholder mapping is one of the techniques that you can use.
So who's on the hook really? Ultimately the product owner.
https://linktr.ee/johncolemanxagility - social and podcast links
https://linkpop.com/orderlydisruption - order training from right here