The Commander in Chief
We’ve described situations where product owners aren’t given the proper time or authority to fulfill their role properly. But the opposite can be bad, too: A product owner who wields too much power and doesn’t listen to anyone else.
Here’s what that looks like:
The product owner is an almighty being who doesn’t collaborate because he is the single decision-making authority. The development team is expected to obey this person’s every command and the team’s input is not welcome. The Scrum master makes sure the development team doesn’t deviate whatsoever from the product owner’s orders.
During rare meetings with stakeholders, the product owner describes how things are going to be and what is happening. It’s purely a status meeting and no input is asked for because the direction of the product and features are determined by the product owner, and the stakeholders will just complicate decision making. Sprint reviews are for the product owner to approve or reject the results of the sprint; stakeholders are not required nor invited.
During sprint planning, the product owner arrives with a goal and has prefilled the sprint backlog based off of a velocity he has set. The event is simply held to create order for the next sprint and tell the team what to do. The product owner often questions estimates of product backlog items because the tasks sure seem easier than the development team’s estimates indicate. When the sprint is underway, the product owner attends the daily scrum to get a status from each team member and to make sure that the Scrum master has them working at full capacity. The development team doesn’t deviate from the plan outlined by the product owner in the sprint, even if that means sacrificing quality.
If these scenarios made you cringe because you live them every day, don’t fear–there’s hope even in these situations! Perhaps we need to look at the “Commander in Chief” PO a little differently.
Being a product owner can mean being lonely, and that might be what’s causing this controlling behavior. Product owners have an immense amount of pressure on them: stakeholders have high expectations, development teams need clarity and support, and customers are demanding. Coupled with the fact that this might be a new role for the person or the company, the product owner could feel really scared and stressed. As a Scrum master, you should partner with the product owner by helping him build the tool set he needs to be successful. And sometimes, you might be able to help just by asking the PO, “Are you okay?”
Sometimes POs just need a breather
by
Todd Miller
Todd Miller
While I’ve spent a majority of my Scrum career working as a Scrum master, I’ve been a PO three times and I’ve learned a lot from those experiences. It can be a stressful, lonely job. I’ll never forget a particular day that I was really struggling with stakeholders: I was involved in several extremely tense conversations that resulted in screaming matches between stakeholders who eventually started screaming at me, too. As I left the meeting with them and walked past the development team, I was barraged with questions about product backlog items. I have to admit that, because I was in a terrible mood, I wasn’t very gracious or helpful to them.
Later that same day, I received an invite for a late afternoon meeting with a few Scrum masters. I cringed at accepting it, as I anticipated that another missile was heading in my direction. I walked into the meeting room, sat down, and asked what they needed. To my surprise, they asked me what I needed and asked if I was okay. Turns out they simply wanted to make sure I was doing alright. We ended up just chitchatting and talking about sports. It gave me a chance to take a deep breath and decompress, which I sorely needed. It was awesome!
So if your PO seems really frazzled or grumpy, ask him how he’s doing. A little empathy and understanding can go a long way toward making him feel less stressed and alone.
It’s important for the product owner to take a collaborative approach with stakeholders, team members, and customers. If they instead act as a commander-in-chief, there will be little transparency around decision making, which in turn will cause the product backlog to lack transparency. Without transparency into the product backlog, the product owner may end up adapting the product backlog without technical or stakeholder input. This lack of transparency leads to a product backlog that’s not ordered in a way that contributes to the success of the project.
As a Scrum master, you need to be willing to confront a product owner who has let the power and accountability of the role go to their head. But at the same time, don’t assume that that’s what is taking place: First, try asking your PO if he’s okay and how you can better support him.
