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:
- If the organization wants to do Scrum, why have they assigned a non-agile Product Owner to the role?
- 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?
- 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:
- Addressed by the whole Scrum Team in the nearest Sprint Retrospective, if it's not preventing progress within the current Sprint.
- Used as a reason to stop-the-line and collaboratively swarm over the problem, if it's actively risking the current Sprint Goal.
- 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.