#005 - Hands-On: Tackling "volatilizing product owner involvement" in agile development teams

Note: This is a hands-on article. It contains practical advise for a work or private related domain.

During the last 4 years I worked in alternating roles in agile software development environments with different assignments in requirements-management, development-management and test-management. Team-sizes varied from 9 development teams to one development team.

During this time I found from personal observation, that amongst many existing causes for potentially decreasing quality of deliverables and releases one particular factor an higher impact poses, than the other ones.

That is: Product Owner Involvement.

I know, this might sound to easy and obvious to many but in the end it has real impact on the following exemplary KPIs in agile development:

• # of released features
• # of releases in general
• # of open and solved defects per release
• Quality of features

and ultimately satisfaction of the customer, what shoud be the central goal every member of the development team has in mind.

The product owner (PO) is according to agile principles not the one who makes the final decisions for how things are being done inside the development team but he or she is the central decsion making authority for the feature-roadmap and therefore for the shape of future releases. In this role it is obvious, that the role of the PO has high impact on the outcomes.

When a PO does not carefully build the product backlog in accordance with all stakeholders this leads to:

• Unclarity & increased complexity in development
• and more defects in quality management

While this relation is not obvious in early development stages, the impact increases at the end of a development iteration.

Many who have worked as contributors to agile development teams may have encountered this issue and the side effects on the development stream.

So I posed the hypothetical question: Why is it, that product owner engagement sometimes decreases and what might be possible soultion approaches to improve or prevent that?

In the search for an answer the following 4 causes from my personal POV became obvious drivers for what I call "Volatilizing product owner involvement":

1. Missing 1:1 Relationship between a Product Owner and a development Issue (which might be a user story, a defect, etc.) / Explanation: Often new issues like defects are not correctly assigned to one responsible product owner that has the main responsibility for the solution to that defect. In such a case involvement decreases as the urge to take care of an issue is weakened.
2. Increasing technical complexity when non-technical POs are assigned with the role / Explanation: In many work environments it is common, that non-technical employees with other key focus skills are assigned with the role of a PO. If the role of the PO in his particular development team needs dedicated technical knowledge, that cannot be covered by a technical proxy PO, this situation might lead to decreasing involvement.
3. High number of topics in diverging knowledge areas / Explanation: Have you ever worked in agile development and heard the following phrase in this or other forms: "The product owner has more to handle than a single person can do adequately." Then we share something. The role of an PO might often start out relatively 'doable' but in many cases expands exponentially with new releases and sprints because each time an increment is delivered, the 'old stuff' has to be kept in mind when creating new features. This often creates a mixture of different required knowledge domains that have to be covered by a PO. If it gets too much, consequently the involement decreases in certain areas.
4. Many small and operational (but nevertheless often required) issues / Explanation: Do you know what happens when you are a PO? Exactly: Everyone is coming to you with their wishes and their bright ideas and their tremendouds improvements, becasue you 'own the product'. Besides this, often there are tons of other issues to be handeled. Communication with other departments, customer contact, tool handling, financial review and sometimes even employee development if you own a manager role besides the PO role. This overload leads to decreased involvement as well.

"Volatilizing product owner involvement", caused by the mentioned topics, describes a situation where the motivation of a product owner to proactively drive the development in his responsibility area is lowered by the mentioned causes and other potential causes that I did not list.

And as indicated "Volatilizing product owner involvement" leads to negative impacts for product quality and team performance.

So what to do?

To every problem there is a solution. Here we have the same situation. Each of those four mentioned issues can be tackeled with the following suggested countermeasures:

1. Missing 1:1 Relationship between a Product Owner and a development issue (which might be a user story, a defect, etc.) / Countermeasure: Create a clear delegation board or matrix for each development area that you have covered in your agile organization. This delegation matrix defines who is initially to be assigned with new user stories, with new defects, with new content requirement and other things. Even if the first assignment might be wrong and the development issue belongs to another assignee, the first assingee has the ownership and the responsibility to correctly process the issue.
2. Increasing technical complexity when non-technical POs are assigned with the role / Countermeasure: The issue itself holds the solution. Whenever a PO does not possess the required skills to handle all areas of expertise, enable the possibility to assign proxy POs for those special expertise areas. Example: If a development team has to design a new 'gigantic' API for your product and the PO is not able to adequately support the job, name an architect as proxy PO who can in peer review with the PO do the work.
3. High number of topics in diverging knowledge areas / Countermeasure: It is possible, that proxy POs might be a viable soltion approach in this case but if too many knowledge areas are combined in one development team it might be time to split teams and assign a new PO for another area in the development organization. Lets assume, the database for a product gets more and more complex to handle, it might be an indication that database development need to be covered by a dedicated development team.
4. Many small and operational (but nevertheless often required) issues / Countermeasure: This one comes from a simple truth. Sequential completion of tasks leads to better results than multi-tasking many isses at the same time. It is no agile-problem but a general problem in many work forces. Nevertheless in the agile envionment the answer is clear.

A product owner is a product owner and should be nothing else. The responsibility to create a top notch product that satisfies a real market need is a goliath task itself. All distraction that does not contribute to the development of the product shall be governed by other people.

Of course these are only suggestions and might not work in any given circumstance. But if you work in an agile organization and have the sense, that some of the above mentioned KPIs suffer from decreasing quality, it might be a fitting time to do an assessement of the status quo with the mentioned problems in mind.

Never rest and never settle when it comes to quality. Your customers will gladly appreciate it with an increased purchase or retention rate and a higher overall satisfaction.

Thanks for reading,

Johannes Ehrhardt