The Agile Architect
Protecting Your Software Investment from Fickle Product Owners
Our Agile Architect discusses strategies for working with a product owner that can't hold to a decision long enough to see it realized.
As software developers, we get our feature priorities from our product owners. But what do we do if our product owner can't keep a feature prioritized long enough to allow us to complete it?
When your product owner keeps changing priorities, it leads to an extremely ineffective development team. Features can't be completed and are left orphaned on source code branches that slowly age, become stale, and are eventually unusable. The team becomes demoralized because they can't deliver. The product owner becomes frustrated because the team is not realizing their vision.
Why Might a Product Owner Be Perceived as Fickle?
Before talking about ways to deal with a fickle product owner, it's important to understand what drives their behavior. Here are some of the causes I've encountered:
Personality: The product owner is simply unfocused in their work and distracted by the latest shiny thing.
Unorganized: Because the product owner doesn't work from a prioritized list of features, everything that comes at them seems to be the most important thing. They forget all the other most-important things they've already assigned to the team.
Greed (in a good way): The product owner wants more for their customers faster than the team can deliver. Thinking that a feature can't be completed until it's started, they push for every feature to get started right away, thus blurring the distinction in priorities.
Timing: With a seasonal product, e.g. holiday cards, missing a deadline is an all-or-nothing proposition. What seems to be fickle product ownership to the team is actually the PO recognizing that a release won't be out in time to profit from it. The PO finds themselves leaping from one must-have release date to the next, missing each one because the team is still dealing with the after-effects of the previous missed deadline.
Inexperience: The PO simply doesn't know how to effectively plan for delivery of the product. Rather than shielding the team from outside influence, the PO actually magnifies it, turning minor issues into major crises for the team. For example, when a bug is discovered that has a work-around, rather taking on the relatively simple and quick task of communicating the work-around to the users, the PO calls stop-the-presses in order to create an emergency bug-fix release.
Lack of control: another individual or department may be levying unrealistic requirements on the PO.
Non-agile stakeholders: Other departments in the organization may not be operating on agile principles. Their dysfunction reigns down (pun intended) on the product owner and bleeds through to the team.
Strategies for Dealing with a Fickle Product Owner
An agile team's reaction to a fickle product owner ranges from the proactive "Hey kids. Let's teach our product owner how to play with others!" to the defensive "Alright troops! Let's document the crap out of everything!" Here are some strategies you may find useful:
Educate your product owner. Push back and retrain your product owner. Track metrics showing how very little is getting released while there is a large inventory of work that can't generate business value.
Measure the flow and the waste with a cumulative flow diagram. Include the stories that the PO has deprioritized to dramatize the growing inventory of partially-completed stories.
Measure the waste explicitly. Show visually how many hours have been spent on stories that were started but not delivered.
Build an alternate timeline illustrating what the PO could have had if they had allowed the team to complete their work. When building the timeline try to be as realistic as possible. Collect all the dates when new features were introduced to the team. Start with the earliest features and project when they would have been finished if the team had been allowed to complete them. As a feature finishes and the team has capacity to accept new work, look at the features that were important to the PO at that time and pull in the most important one. Repeat this until you work your way to the present. You should have a fictitious list of "completed features." Use this in a discussion with your product owner, perhaps in a retrospective, to discuss which outcome is more desirable. Be objective and open to the fact that the product owner may still believe they made the right decision. And that might just be okay.
Change how you deliver. Rather than fighting against it, think about how you can work to accommodate frequent changes in direction while still banking the work you've done.
In the ideal case, you would break down features into smaller, deliverable sub-features. These sub-features may have to be modified to stand on their own but they provide a path forward to the larger feature. There may be perceived additional cost when building deliverable sub-features rather than the entire feature up front. However, a feature that is never delivered provides no value so the extra cost, real or perceived, is justified.
In the less-than-ideal case where you can't deliver even a sub-feature before the product owner redirects the team, consider ways to keep the code that's been written living within your system. Rather than sticking the code on a branch that quickly becomes stale and out of date, with every commit, think about how to build the software in such a way that it can remain in the production code with all of its automated tests running with each build. (See my column on Branch By Abstraction.) As new functionality is added, as the code base is refactored, the code for the deferred feature is kept up to date. The trade-off is that if the code is never released, it just sucks time from the team as they have to constantly refactor it and maintain the tests. So consider having an expiration date after which you delete the code.
Another strategy is to allocate a portion of the team's capacity to the product owner's feature du-jour. Keep the rest of the team on track with the features in flight. Depending on your relationship with your product owner, this may require a conversation and agreement on a commitment point. This is the point where the product owner and the team commit to completing the feature. The only reason to stop work on the feature is if it has been deemed no longer needed, in which case the code is deleted and the team pivots to other work.
Change your team. Another opportunity that is often overlooked by a team is to change the team itself. Increase capacity until you can deliver before the PO changes their mind. Alternately, change teammates until you have a team composition that can respond effectively to the product owner's style. I'm not advocating skimping on agile disciplines. Rather, I'm suggesting that different people have a different dynamic when working together. Changes to the team may result in better outcomes either because the team now has the right mix of skills to respond better to the product owner's requirements, or because the new personalities mesh better with the product owner, allowing for change that couldn't happen previously.
Change your product owner. Sometimes the product owner, as visionary for the product, is not focused on delivery. Their job is to dream big. The lower-level details of delivering software are not something they are interested in or very good at. Get them some help. Make the current PO the product visionary or evangelist -- after all, that's what they're doing -- and bring in someone to work with them in a true product owner capacity.
Final Thoughts
Dealing with a fickle product owner can be tricky. No one acts without reason. What the team sees as fickle behavior, the product owner sees as perfectly rational. By approaching the problem objectively, considering how to change the team's behavior as well as the product owner's, you increase your chances of finding a successful outcome for everyone.