Is it a People Problem or Agile Problem?
First, there's lots of good advice out there on how to work with difficult people. Keep your cool and pick your battles suggests one post. Another post recommends don't keep silent or move to problem solving. A third post reminds you to be tolerant of different approaches but handle aggression aggressively. If your dealing with a difficult person then you should follow some of the best advice out there on handling people.
But a difficult product owner may or may not be a difficult person. A difficult product owner doesn't care about agile practices or about technology best practices and at the extreme probably prefers to just bark orders and see high quality results completed on time. They want minimal interactions with the team claiming they are too busy on other product related matters. If they need something immediately, it's the team's issue on how to deal with it mid-sprint. They don't subscribe to developing minimally viable products and over-complicate their product requirements. This product owner has probably committed to a scope and a deadline to his stakeholders and doesn't care that it doesn't align to the team's velocity or that sprint capacity must also manage technical debt.
Advice For Slowly Turning Around Difficult Product Owners
So given all types of difficulties, here is some basic advice on how to handle different situations.
- Make sure the team is truly executing - If you're saying your agile, but exhibiting poor execution it's really hard to get a product owner aligned. Make sure you complete sprints on time and meet acceptance criteria for 'done'. Lower the velocity and don't commit to poorly written stories to stabilize delivery. Without a stable process, it's very difficult to align an antagonistic product owner
- Stick to the core of agile practices - If you wave off the fundamentals, then the process will break down and you'll never see the fundamental benefits of being agile. Start and end sprints on time. Have standups and demos even if the product owner refuses to attend. Most importantly, overly communicate the timing of meetings, when artifacts are due, and agile practice rules to reinforce responsibilities and schedule.
- Prioritize for the Product Owner - There are two ways to effectively force a product owner to prioritize. First, if they haven't done so before sprint planning, do it for them. Just schedule sprint planning earlier, communicate the priorities, and then expect them to react and give you changes. It's not efficient or collaborative, but practical. Second, use commitment to prioritize and don't commit more than your velocity. Again, if you don't commit to the expectations of your product owner, expect them to request changes so make your commitment sessions earlier to accommodate the inevitable back and forth.
- Learn to say NO - This won't be easy because a difficult product owner's response to a "no" will often be a meeting request, demands for documentation, or escalations to management. So pick your battles, but don't be shy to say no to key issues such as significant changes in a story's scope, requests to reprioritize stories mid sprint, or changes to release schedules that are not realistic.
- Provide only appropriate reporting - Providing too much reporting detail on the agile practice is a death trap. Difficult product owners will often ask teams for additional reports/metrics in an attempt to micromanage the team or escalate to management their version of productivity or quality issues. Be transparent and be honest, but control the flow of information and the message.
- Keep management informed - but avoid escalating every issue. Management needs to know about the issues and should handle systemic ones, but they can't do the team's job of handling the day to day issues.
- Keep the team motivated - If you have a product owner that doesn't show appreciation to the team, then compensate for it. Put out thank you notes and keep management informed on the team's successes.