How To Handle Difficult Agile Product Owners

Difficult Agile Product Owner
There are many product owners that understand agile practices, enjoy collaborating with technologists and leverage data to make sound prioritization choices. But if you've practiced agile long enough you've probably experienced a dark product owner who's exhibited some of the bad behaviors of product owners that I posted a couple of months ago. At the extreme, these product owners only care about the results or themselves and consistently pressure (sometimes bully) the team to do things that violate the agile practice. So what do you do if you're on an agile team and working with a difficult product owner?

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.   

These things tend to sort out, but the team has a role of moving the ball forward despite the obstacles. Eventually, either the product owner gets onboard because he or she sees the team delivering or management steps in and makes organizational or responsibility changes.



No comments:

Post a Comment

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share