The True Value of the Product Owner
With over seven years of Agile adoption experience under his belt, a Zone Leader talks about the importance of keeping the value of the Product Owner in check.
Join the DZone community and get the full member experience.Join For Free
With a high degree of Agile adoption in Information Technology, the role and importance of a Product Owner is something organizations determine based upon not only their commitment to the Agile methodology, but in the sacrifice they make by assigning a subject matter expert to work alongside one or more feature teams. This action is similar to an athletic team temporarily sending their best player to a farm team, to act as a mentor.
While it is wonderful to have dedication participation from the business on feature teams, I have noticed some challenges that can happen when the Product Owner is overvalued.
The God Complex
In most cases, the Product Owner is the scribe behind the epics, features, and stories that will be implemented. The Product Owner provides an understanding of both the current state and the intended future state — which is key to making sure the delivered solution matches the expectations employed by the business. The caution here is the power behind such a premise and an abuse of that power can lead to challenges with a feature team's productivity.
While working on a project, we reached a point in the project where the implementation of a set of features did not fully match what the Product Owner had in mind. The underlying functionality was perfect, but the placement and delivery of the functionality was an issue. The lead developer for the team provided insight on why the employed approach was utilized and explained how taking the alternative approach would lead to performance and support challenges if utilized.
Instead of talking through the issue and trying to gain a better understanding of the reasons behind the impasse, the Product Owner made it known that his vision was the vision that was to be delivered. The team ultimately rebuilt those aspects of the application, which led to those known performance and support issues occurring once the feature was delivered to all users.
Release Often, Not In Big Bangs
Agile is built on the premise that smaller iterations can be delivered more frequently when compared to alternative methodologies. However, the reality is that multiple iterations are often grouped into a single release. The biggest reason is that the Product Owner indicates the business is not ready for the new features and the preference is to release several features at once in order to minimize the impact on the end-users.
Taking this approach allows the business units to operate in a different fashion than the feature teams. Their excuse is that it takes more time to update the necessary documentation and training materials. If this is truly the case, then the documentation and training aspects should be analyzed in order to determine how these areas can adopt a more iterative approach.
For Agile adoption to be effective, it must be adopted by all aspects of the business which are delivering features.
Get Releases In Front of Users
If there was one lesson that continues to be learned, but not implemented, is not adjusting the time it takes to get releases in front of end-users. Too many times, features are held up for additional analysis by the Product Owner, when they could be pushed to alpha or beta users to gain additional feedback.
This goes back to the Product Owner being the gatekeeper between the feature teams and the scores of end-users who will utilize the aspects that are being developed. While the Product Owner may be a rock-star in the eyes of the business, one opinion is not better than real-time feedback from early adopters eager to utilize the new features.
Since I started utilizing the Agile methodology (over seven years ago), I have always been an advocate for feature flags. Feature flags allow groups or users to gain access to new features, without introducing the features to everyone. They can be granted and taken away as needed — based upon feedback that is being provided. While feature flags require additional time to setup, implement and manage, the value that is returned via additional feedback far outweighs the actual costs.
I've noted before how my son has always enjoyed playing first-person video games. If I had more free time in my life, I would engage in the experience, too.
The biggest complaint I hear from my son, as an avid gamer, is when a particular game has a gun that is overpowered when compared to alternative options. This causes frustrations to the point to where teams set up rules where such weaponry is not allowed. In short, an overpowered weapon takes away from the experience.
When the value of a Product Owner is overpowered, the team and resulting solution is compromised. As noted above, subpar implementations are forced into adoption, features are grouped into a multi-iteration release, and feature teams fail to gain feedback from a large set of future end-users. These are just three quick examples of the consequences for not keeping the value of the Product Owner in check.
We have to keep in mind that an Agile team is a team, which each member is not more important than the other, that their roles help to formulate the necessary equation to delivering solid features, quickly and adapting to any feedback that is provided.
Have a really great day!
Opinions expressed by DZone contributors are their own.