7

As a Scrum Master, recently attended a meeting set up by PO with stakeholders, one stakeholder was concerned that the budget was not being spent properly. It got heated.

At the meeting, I was not sure how to intervene since it was the PO's meeting and since it was the PO's meeting did nothing.

I was thinking at the back of my mind to either:

  • defend the PO and budget
  • defend the team, since they were kept busy delivering items from the backlog
  • Bring focus to the meeting by telling POs to keep focus on delivering high value items in the following sprints

I am slghtly confused about what to do in this type of situation, what is the best way to handle it? Am I allowed to participate if it is PO's meeting?

  • Just as an aside, I am quite staggered that the answers all display a tendency to consider the stakeholder correct and has to be listened to. The surest way to destroy a product is to let every stakeholder have input into decisions. Design by committee is a terrible way to develop. – Venture2099 Dec 26 '18 at 9:05
  • I don't think scrum or agile has cured stakeholder management and organizational change resistance. Validating stakeholder concerns and including them on decisions in some framework is a proven method for OCM to increase acceptance and reduce resistance. If you can explain how scrum cured these issues that have plagued projects for thousands of years, I'd like to learn it. In my experience watching and participating in projects using agile, resistance has not been touched. But that is only my experience and is obviously not generalizable. – David Espina Dec 26 '18 at 13:03
  • Who said Scrum solved these? You want anymore strawmen in your argument Dave? My point still stands. Every answer has painted the stakeholder as somehow being right and deserving of consideration. As to your wholly biased interpretation of Scrum, I am disregarding that for the transparent nonsense it is. – Venture2099 Dec 27 '18 at 9:08
  • Validating a position doesn't mean it's right or should ultimately be followed. It means it had validity and should be heard. A real distinction. The OP is asking how to handle the stakeholder, not about scrum rules. There is definitely a lot of bias about scrum and I don't think it's all me. It is all over this exchange. – David Espina Dec 27 '18 at 9:23
  • Course you don't think it's you. I am shocked, shocked I tell you. – Venture2099 Dec 29 '18 at 12:33
7

I am drawing assumptions on your PO's agenda, based on my experience of other PO meetings, and discussing a stakeholder's objections on spend would not be consistent with that agenda. The PO, or you, or another leader of the team, should acknowledge the issue, validate the issue, and then table it with a promise of an immediate meeting to discuss further. Defending anything in the meeting would be unwise and allowing the debate to get heated in front of the rest of the team is unproductive.

There are obvious reasons why a stakeholder would be upset with the spend: spending on the wrong things, over budget, or no controls over the budget to even know we you are in the spend. It would be good for your project's overall health to listen to the complaints and then run each one down so the stakeholder can get on board with the project, or if unable to run down, then escalate to the project's sponsors to intervene at that level.

  • If the team are using Scrum effectively then the Product Owner is sole source of priority; I.E how they spend the budget as an empowered P.O is up to them. There are no "wrong" things. – Venture2099 Dec 24 '18 at 8:42
  • How does that resolve a stakeholder disagreeing? They are simply told they are not allowed to disagree? That sounds ineffective to me. – David Espina Dec 24 '18 at 9:36
  • It doesn't matter how it sounds. The OP is using Scrum and the P.O role is very clear. They have authoroty. This does not invalidate the rest of what you are saying, but that specific part, is very clear. – Venture2099 Dec 24 '18 at 19:50
  • 1
    @Venture2099 While the Scrum Product Owner is the sole owner of the Product Backlog, that doesn't really mean that stakeholders, sponsors, or organizational oversight functions have no role to play in reviewing the backlog or providing input and feedback to the PO. All Product Backlog functions operate through the Product Owner, but the PO remains answerable to the organization. Ultimately all agile frameworks rest on delegated authority and collaboration to make things work. – Todd A. Jacobs Dec 25 '18 at 17:01
  • I don't disagree with that but my point remains; telling a P.O that a stakeholder is allowed to inform them that "they are spending money on the wrong things" and that it has to be "acknowledged" is basically undermining the P.O role and autonomy. – Venture2099 Dec 25 '18 at 23:24
5

TL;DR

I was thinking at the back of my mind to either:

  • defend the PO and budget
  • defend the team, since they were kept busy delivering items from the backlog
  • Bring focus to the meeting by telling POs to keep focus on delivering high value items in the following sprints

The correct answer is "none of the above." Your goal as Scrum Master isn't to defend anything except the process. A good Scrum Master acts as a coach, an educator, and (when necessary) a process referee.

The problem you're describing is one that often results from poor process transparency, or from a product/portfolio management methodology that lacks rigor, objective metrics, and (most importantly) stakeholder buy-in. There are a number of existing approaches for dealing with that, which I addressed in a previous answer.

Below, I offer a process perspective and an interpersonal perspective on what the problems may be. I also offer some practical suggestions on how to address them within the role of Scrum Master.

The Process Perspective

From a process perspective, a Scrum Product Owner is responsible for managing the Product Backlog. In practice, this often means managing stakeholder expectations about how priorities are being set and (indirectly) how project budget is being allocated.

There are a number of techniques for getting buy-in for prioritization and budget, but they all ultimately boil down to good communications and selecting metrics everyone can agree on. If stakeholders are not already on board with the Product Owner's priorities, or if the project sponsor isn't backing the budgeting process effectively, then this is certainly an area where a good Scrum Master or agile coach can facilitate communications and help the organization to collaborate on budgets and priorities more effectively.

The Interpersonal Perspective

While it's not your job to defend the budget or the Product Backlog priorities, there are some interpersonal techniques that can make it easier to defuse this sort of unproductive meeting. In general:

  • Don't get defensive or pick sides.
  • Capture any concerns or objections raised by the people in the meeting.
  • Be willing to (politely) observe that the meeting has created action items for the participants, and that it may be time to adjourn to consider them.
  • Discuss the meeting with the Product Owner afterwards, and work together to evaluate alternative approaches.
  • If welcomed by the Product Owner and the stakeholders, offer to coach the organization on agile prioritization and budgeting techniques.
  • Suggest hiring an agile coach or consultant if the process is so far off the rails that it endangers the effectiveness of the project.

In all cases, your goal is to facilitate communication, not defend or change the current process. As long as you're continuously improving team and organizational communication, visibility, and transparency, then you're fulfilling the Scrum Master role properly.

0

In my experience, these situations happen due to a lack of understanding from all sides. It is probably a good idea to recommend that the team (or only the PO/yourself) start by listening very carefully to the stakeholder and ask as many questions as necessary until you are 100% sure you understand their reasoning and then you should prepare to explain why the budget was used in the way it was as well as coming to an agreement on the course of action to solve the issue

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.