Agile Journal - The Product Owner: Choosing the Right Person for the Job

Home

Articles

The Product Owner: Choosing the Right Person for the Job

Written by David Webb

Saturday, 06 October 2007

Agile teams large or small, co-located or distributed, have one very important common denominator: the absolute imperative that a strong product owner be established before any work begins. Arguably the strongest, or weakest, link in any Agile team is the product owner. At odds with this basic fact is a startling oversight of this role at the outset of many projects. Add to this a multi-site outsourced development team and it's no wonder successful enterprise Agile adoption is slow going. What makes a good product owner? Why is this role critical to the success of any Agile project? How should this role be supported within the team and organization? These fundamental questions will be addressed herein.

Defining the Product Owner Role
The main responsibility for a product owner is to keep the team integrated and focused on the ‘greater good' of the project to ensure the system creates business value. Break this down and the product owner has some very specific tasks to manage:

Ensure the finished product meets the business needs of the company.

Decide the incremental release schedule and the function of each.

Create and manage each backlog during every sprint.

Prioritize stories according to business impact and reprioritize if this changes.

Sign-off on all work once it is complete (the ultimate responsibility).

Provide feedback to the development team and adjust as needed.

Beyond this, and perhaps the most important responsibility, is he is charged with stakeholder management and communication. The product owner must straddle two worlds: the Scrum team world and the customer world. He must prioritize the customer's interests and represent them within the Scrum team. Similarly, he has to represent the Scrum team's needs within the customer community - a sort of ‘devil's advocate' for both the Scrum team and the customer. The ability for a product owner to keep the development team focused on the highest priority, most strategic pieces of the build is a major factor in what makes Agile so successful.
Without a strong product owner and appropriate effort by a company to support this role, the responsibility must be split and piled onto the existing workload of the business analysts, lead developers, technical project managers, business project managers, etc. This is not an effective or efficient workaround and will lead to problems down the line such as the development team working on the wrong priorities, and in a worst case scenario the wrong functionality all together.

How to Identify a Product Owner Candidate
Success can not be forecast almost solely by personality traits for the majority of roles in an Agile team. Product owner is such a role where the character attributes are key. Take a good look at your product owner candidate. What sort of person is he? Is he the sort of person that can deal with multiple stakeholders, make clear decisions, impact group decisions, all the while articulately demonstrating the trade-offs needed in an Agile project? This character attribute is critical in order to prioritize the business value and get a working product out of the door in a timely manner without the development team melting down.

Does the product owner fill you with confidence that he will stand up and fight for his decisions or is he a ‘shrinking violet' that will cave in at the first disgruntled user and then change his mind at the second? The need for this sort of self-confidence and strength of character will be tested often when executing an Agile project.

This product owner must embody and demonstrate an exceptionally sophisticated communications skill set. You'll be asking the product owner to prioritize according to business value and to make tough decisions which he will have to defend to the customer stakeholders. Weak product owners will fold here and place blame on the development team, weakening the overall value of the product and integrity of the development team This all has to happen smoothly while avoiding a breakdown into finger-pointing and a destructive blame-game. Without these ingredients, the product owner will not be able to do an effective job - in extreme cases, failure here may be terminal for team moral. Bad blood can last a long time and cause management much frustration.

Supporting the Product Owner
When implementing Scrum, where you have a highly collaborative team environment that is co-located, a product owner with the aforementioned positive traits will be productive. If you now try to create a distributed Scrum project where the product owner is not co-located with the development team, cohesion starts to breakdown. This is an emerging scenario for outsourcing relationships where a combination of travel, and tools, and processes will enable the Scrum team to create greater collaboration while keeping the sprint on an even keel.

With multi-site distributed teams, it is strongly recommended to meet face-to-face at the start of each release plan or periodically; every three months is recommended. It is true that planning can be done over the phone using collaboration tools such as WebEx, Skype, or NetMeeting. However, even though the output may look the same, there is a distinct lack of chemistry and familiarity within teams that only rely on collaboration technologies. Developers are people and they won't bond with programs - personal rapport goes a long way. Face-to-face meetings are ideal for hammering out how to communicate amongst the team. Topics can include how often the product owner will be expected to give feedback and which metrics should be tracked and reviewed by the team to incentivize the correct behavior in the team's particular environment.

Travel such as this may cost $5,000 to $10,000 and management will almost always refuse at first, citing the investment made in the collaborative tools. Simply remind them of what the cost would be if the development team delivers the wrong functionality or of the accrued cost of developer run-rate if they have to start over - common symptoms of a team that does meet regularly. The impact on the company will be much greater than $10,000. If you have a team of developers doing the "wrong" thing for a period of time and then getting into a blame situation with a product owner and vice versa, the cost can often be the entire sprint or even the project.

Creating a Support Structure for the Product Owner
The product owner shouldn't be an island unto himself - there should be support from the development team and the Scrum Master throughout any project. Like any good team, Agile project members must always work together to help each other out. One such helpful practice is for the team to establish metrics to incentivize keeping the product owner true to his role. Is the product owner frequently giving the development team feedback? Is he checking his decisions with customers and giving their feedback back to the developer team? Has the product owner truly been the ‘Devil's advocate' for both the Scrum team and customer base? Is the product owner diligently reviewing the deployed code functionality? Is he looking at what has been delivered, assessing the business value, and reporting honestly to the customers and stakeholders? Having the metrics themselves is no guarantee of behavior change but the Scrum Master can help determine if the whole team is performing when metrics are tracked and reported at the daily Scrum along with velocity and future backlog. Few things are as effective for behavior change and process adherence than attending a Scrum where you know metrics are being reported that will tell the team how effective you are at your role. Again, Agile projects are team efforts, so all pieces of the team have to support one another.

Product owner integrity is often put to the test when the Scrum team runs short on time and not enough business value has been put into the release. When these two conditions exist, the product owner often pushes the development team for functionality over quality to make the build deadline. This is dangerous and as the guardians of code quality, the development team must stand firm. The development team must always follow the sashimi rule - where every piece of functionality delivered by the developers is fully tested and re-factored. [i] This positive tension and collaboration is what make Agile projects so special.

The bottom line is that product owners are absolutely necessary and have one of the most difficult jobs to do. Candidates must be evaluated with the right criteria for the role. They have skin in the game with all levels of the project - developers, managers, executives, outsourcing providers, etc. In order to do this job properly, product owners need to have strong confidence, teamwork and collaboration skills, and discipline. Tools, processes, and metrics can help with the discipline but the other attributes require a certain type of person.

About the author
David Webb currently serves as Agile Practice Lead and Engagement Manager for Exigen Services. He has been working with distributed Agile teams for more than five years, establishing practices and metrics to effectively manage and execute offshore Agile projects. David lives in London, England.

[i] See "Agile Project Management with Scrum" by Ken Schwaber, p. 55, for a discussion of the sashimi rule.

Comments (2)