The Product Owner: Choosing the Right Person for the Job


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

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.