Product Owner micro-managing developers - advice needed
I have a product owner that is micromanaging some of our developers. Specifically, this person is rewriting code for the devs (the PO used to be a developer). I have not witnessed this first hand but was told about it (I'm the scrum master on the team). Anyone have advice on how I can gently remind the PO of their role in a scrum team? If I need to have the blunt conversation of "don't do this" I will but I'd like to try a softer approach with this person first.
Would appreciate any advice!
Are you sure the PO stopped being a developer? Was it a decision he or she was happy with and was it helpful to others? Why was that decision made and by whom?
There is nothing that says an individual that fulfills the Product Owner accountability can't also help fulfill the Developers accountability. In fact the Scrum Guide states in the section that describes the Daily Scrum that:
If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
Remember that the 3 accountabilities in the Scrum Guide are not job descriptions or job titles. There is nothing that says someone has to have a job title of "Developer" to fulfill that accountability.
However, this individual seems to be acting as a command-control manager for the other Developers. That is the part that you might want to have a conversation about. They are taking away an opportunity for the others on the team to learn, self-organize, self-manage to deliver the usable increments of value. This might be a conversation worth having with the individual.
It's natural from people to struggle to relinquish control of things as they grow into leading roles. It sounds to me that this Product Owner is struggling to move out of their previous territory.
I'd try to determine if this person is adjusting/contributing to code out of sheer *opinion* or if their skill is significantly different and better than the others. I've dealt with both scenarios:
- If the person is largely driven by opinion in this case ("I want the code to be this way, I prefer my way to the way others wrote it") then they need help to relinquish control and to trust. The others in the team will have to earn that trust and prove their code is up to standard.
- If this person is in highly skilled and their code is objectively better than the others', then they need help to share knowledge, patterns, techniques with the other developers.
Either way, I'd consider pair-programming, mobbing, and technical demonstrations. The team must establish acceptable patterns and must grow to know and fully understand each other's code styles/tendencies.