How to coach a domineering PO to let go and allow a team to become self-managing

Question

The Product Owner that I am working with has agreed "to try this self-organising stuff" on our Scrum team.

Long story short I convinced her that there are 2 paths for the team. One in which she directs and manages the team but also largely takes responsibility for the output and upkeep or alternatively we can work together to build a self-organising team to take ownership and responsibility. She has agreed to try the latter.

Has anyone tried this or can recommend a method for essentially teaching and coaching this concept to a Product Owner who is open to change, but is very dominant and directive over the team.

I was thinking of just mapping out all her behaviours on Miro and explaining what behaviours contribute to what type of team. e.g. always reminding the team to do x,y,z leads to them never taking fully responsibility for x,y,z. etc

Answer 1

While it does seem like a psychological question and doesn't relate to methodologies, I don't agree it's a dead-end and you can't change how people behave. But first you need to understand the underlying reasons for such behaviour, could be:

• She doesn't think others will do a good enough job
• She wants to make things quickly and believes that while others are capable of doing a good job - they won't be fast enough
• She doesn't want to seem (e.g. to her boss) useless
• She likes to boss around, image and whatnot

Once you understand what underlies this "domineering" behaviour you can try to come up with a plan to fix it. Some solutions that may work for some people:

• Ask her to give more control to one or two of your best people. So that the risks (to fail) are low. Work for couple of months in this mode and then start expanding. If she doesn't believe that the result will be of good quality, then any failure may be a throw back. So take it slow, make sure the team is actually capable.
• Try to put more work on her. E.g. talk to higher ups, maybe they can give more projects to her. This results in either of 2:
  • She won't have enough time to follow your progress and thus will give you more control (your win)
  • She'll simply work more and will try to keep dominating, but now since she has more on her plate she'll become more irritable (your loss).
• Someone from the team can study a part of the domain, talk to users, stakeholders and become a better expert in that part than her. Such person will be equal (or close to it) to her during discussions on that particular functionality. This way she may be more eager to entrust it.

Anyway, I'd experiment. I think it's crucial that the team understands the domain very well for this plan to succeed.

But I'd also be careful not to overestimate the team. You keep hearing about self-organizing/self-managing teams as if it's a good thing and we should strive for it. But most of the teams (at least from what I've seen) inherently aren't capable of being self-organized. And moving in this direction may slow down the process and consequently drive away people who're actually capable of doing a good job (maybe it's your PO).

Answer 2

TL;DR

Nope, nope, nope. Just "no."

The question is based on the faulty assumption that you can force change on other people (hint: you can't), and is wishing what seems likely to be poor team composition into the cornfield.

Why You're Asking the Wrong Question

The Product Owner that I am working with has agreed "to try this self-organising stuff" on our Scrum team.

This is a red flag that tells you that a person who you've described as "domineering" is willing to hand-wave agile adoption, or to humor the request without actually committing to any of the Scrum or agile values. This is not a solid foundation for change.

You are asking a question that assumes ab initio that there is some silver bullet that will enable you to change this person, who is currently a poor fit for membership in a Scrum Team. The Product Owner is a member of the team with specific accountabilities, not an authoritarian dictator elected for life. The Scrum Guide says:

Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal...The Scrum Team is...structured and empowered by the organization to manage their own work.

So, any framing of the problem that doesn't start there is destined to be a sideshow of epic proportions, full of drama and tears. Only the Product Owner can change their own behavior, and to do that they have to want to change. Absent that, it's a waste of time.

The Right Questions

The right questions are:

1. If the organization wants to do Scrum, why have they assigned a non-agile Product Owner to the role?
2. If the team wants to do Scrum, why aren't they collaborating with the Product Owner on ways to help one another without stepping on each other's accountabilities?
3. If you (presumably as the Scrum Master) want to do Scrum, why are you asking strangers on the Internet how to gather project-specific information about your team's personalities and processes instead of asking the Scrum Team members?

Don't just ask these questions of yourself. As Scrum Master, you need to have the commitment, focus, openness, respect, and courage to ask these questions of the everyone involved, both separately and together. This isn't your problem to solve; it's the Scrum Team's problem, and leaving it unsolved makes it the organization's problem.

What to Do Next

The Product Owner has a clearly-defined role (pronounced "accountabilities" in the 2020 Scrum Guide), and the Scrum Team should be working together to develop internal working agreements that support (but not counter) the framework's requirements. That means that "domineering" behavior needs to be:

1. Addressed by the whole Scrum Team in the nearest Sprint Retrospective, if it's not preventing progress within the current Sprint.
2. Used as a reason to stop-the-line and collaboratively swarm over the problem, if it's actively risking the current Sprint Goal.
3. Raised with line or senior management, as they are ultimately responsible for team composition and personnel management.

As the Scrum Master, you can and should coach this person as much as possible. Explain the roles/accountabilities, help them understand the agile principles, Scrum Theory, and Scrum Values as best as you can, and even give them some reading homework on agile practices and case studies if you find something suitable. However...

Your Job is to Referee the Process

The Scrum Master is not just a passive servant-leader. The 2020 Scrum Guide has made this clear. A Scrum Master's accountabilities include:

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

So, if you aren't holding the Product Owner (and the rest of the Scrum Team) accountable for collaborating effectively within the Scrum framework, then you aren't performing your role properly either. Your job is to educate them on the framework, help them apply the framework to their problems and processes, and to raise the visibility of insurmountable team composition problems to senior leadership. In fact, the 2020 Scrum Guide says (emphasis mine):

The Scrum Master serves the organization in several ways, including:

• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum implementations within the organization;
• Helping employees and stakeholders [including leadership] understand and enact an empirical approach for complex work; and,
• Removing barriers between stakeholders and Scrum Teams.

The last is especially important. Problems with team composition are (in many organizations) outside the control of the Scrum Team. Therefore, problems that can't be resolved within the team through self-management and collaboration must be made visible to the organization, and the responsibility for fixing team composition problems or resolving HR issues is ultimately the responsibility of the organization's leadership.

As the Scrum Master, you must have the courage and commitment to raise these issues when necessary. If the Scrum Team as a whole lacks the skills, commitment, or willingness to address communications and process problems head-on, then Scrum gives clear guidance on what to do: provide transparency and visibility into the problem to the organization, and then hold the organization's leadership accountable for resolving the things only they are empowered to resolve.

By all means, work with the Product Owner and the Developers to make the problems visible and guide collaboration where possible, but your job is not to die on the hill of interpersonal conflicts within the team. Explain the process, guide the team in applying the process, and help the team adapt the process, but in the end each member of the Scrum Team is fully accountable for their own effective participation (or lack of same) in the process. You can't make them do it, or even make them want to do it.

Scrum is not a silver bullet. It can't turn non-self-actualizing people into a cohesive, high-performing team through magic. It requires commitment and hard work from the whole team, as well as some level of intrinsic drive from the team members. Your primary job in this situation is to determine whether this is a mountain or a molehill, and then help the team and the organization explore the solution space until everyone agrees on an experiment or action plan that's in the best interests of the team as a whole, the current project, and the organization.

Answer 3

Taking a different approach from Barnaby, what I would suggest is to focus on what is needed from her, rather than what is problematic from her. (Or combine the two approaches.)

Go over the Scrum Guide with the entire Team, paying emphasis to the section about roles' responsibilities. Then, if/when she starts asserting her presence into the Team (in a way where it's not obviously a correct assertion), ask her to justify it.

"Can you please explain how exactly this relates to you representing the needs of the client?"

"It doesn't, but we still need to be aware of the impact to the project."

"Thank you, then we'll take it under advisement when making our decision. Anything else?"

Which of course also leaves room for the case when:

"Can you please explain how exactly this relates to you representing the needs of the client?"

"The client has specifically requested to avoid the use of flexing widgets."

"...Why?"

"I'll have to double-check, but I think because they're incompatible with their servers?"

"Okay, well, double-check, please, and in the meantime we'll try to think of something else."

Answer 4

The key will be to have ways to highlight the impact of the Product Owner micro-managing. If you can't demonstrate the impact, there is little to stop them from drifting back to their old ways.

For example:

"Sally was blocked today as they were waiting on the Product Owner to decide what to do next. If they were able to make that decision themselves or in conjunction with the team then it could have saved us several hours."

Answer 5

As already mentioned, you cannot convince a dominating personality to not be dominating.

I'm also not sure she sees the world as you do, which is:

One in which she directs and manages the team but also largely takes responsibility for the output and upkeep or alternatively we can work together to build a self-organising team to take ownership and responsibility.

I.e. that since she's "micro-managing" so she's responsible for the consequences, but if she "lets go" then the team is responsible.

I suspect you may be making an assumption.

She may consider herself responsible either way, or else not understand why she's responsible in either scenario - that also depends on her personality.

Once you clarify her weltanschauung on this subject, then you can try improve the situation.

• If she sees herself responsible "no matter what", then you have to prove to her that giving your team the leeway it needs, will produce better results for her.

• If she holds the team responsible, then you have a harder job; trying to persuade her that she's in charge, while gaining some independence. You're in direct conflict with her entire personality.

Answer 6

Okay, I'm just gonna re-add my "down-voted answer" one more time.

"You're a software project. Goody for you. You organize yourself or self-organize yourself however you want to. Goody for you."

"You are not the Product Owner!"

The Product Owner is the all-important interface between your entire development process and the business which is paying for it. And, did I care to mention that: "the business doesn't know, understand, or care?"

The Product Owner role is far more than merely that of a "proxy." The owner's role is truly that of Janus – "the two-headed god." It is a role that is frequently misunderstood by "those who lie beneath," and it is not a role to be envied. The owner is the one who protects you.

Above your team, "the business" will hold the owner accountable. And, "the owner" will absorb that accountability so that – purposely – none of you have to. But, the accountability is still there.