Being A Better Product Owner

Posted by Mike Bria on Mar 04, 2009

Sections

Process & Practices,

Architecture & Design

Topics

Delivering Value ,

Collaboration ,

Agile

Tags

User Stories

Anyone who has spent any time on an effectively executed agile project can attest to the fact that the Product Owner's (or, in XP, the "Customer's") collaboration with the development team plays a key role in the success of a team. Peter Stevens offers a bit of advice to help people in these roles do this well.

A Product Owner (or equally, in XP terms, a "Customer") arguably has one of the tougher jobs on an agile project. To do the job well, they must keep themselves active and relevant in their domains ("keep their day jobs") while still being an active, participating, collaborating member of their agile development team. It's not uncommon for Product Owners to have a difficult time managing this well, and as a result end up hindering their effectiveness as a participating member of their team. As a result, the team suffers too.

A recent post by Peter Stevens attempts to help Product Owners to know what to look for if they wondering how they're doing, and provides a quick list of tips to help them do a better job.

Stevens offers 4 things to look for as warning signs that the relationship of the team with their Product Owner might need improvement:

• "The Chicken Test": if the team is treating the Product Owner as if they are not a member of the team, then there's a high probability that there is something about the P.O's behavior that is making the team be uncomfortable
• "Failed Sprints, inability to release": its possible that problems with the iteration stories have caused this and can be traced back to problems in collaboration with the Product Owner
• "Who is in charge?": Problems caused by a team receiving mixed signals or ambiguous direction from multiple Product Owners
• "Your team is demotivated": a lack of adequate face time with their Product Owner causing the team to lose motivation

The meat of Stevens' post comes in the form of 3 tips to Product Owners (or XP Customers) for better communication and rapport with their team:

1. Be a team player. Play by the rules.
   Participate fully in all Scrum rituals, including the daily scrum and the retrospectives. Attend the daily scrum and sprint retrospective as an equal participant. Answer the same questions as everyone else. Listen. Don’t use the opportunity to throw your weight around. Perhaps you should offer to keep silent for a sprint or two to build trust. These will help you understand your team and what they need to be successful. They will also understand your problems and challenges better.
    
2. Honor your commitments
   You make an agreement with the team at every sprint planning. Hold up your side of the bargain. Don’t come to your team with extra work during the sprint. Don’t change your mind capriciously - being agile is not the same thing as lacking vision. Protect your team from interference from elsewhere in the company. Yes, this is the Scrum Master’s job, but escalations will come to you.
    
3. Make yourself available when your team needs you
   Come to the meetings on time and stay for the entire duration. Reserve enough of your capacity to meet the needs of your team. If your time is limited, then find out what impact your absence is having on the project. Plan releases around immovable dates, like vacations, trade fairs and other important events, so that you can be present at critical phases in the project.

Not to be repetitive, but its worth stressing that while Stevens presents his message in Scrum terms, this advice is equally applicable to those in non-Scrum environments.  If you're practicing XP for example, then this advice is for the "Customer" and your "sprint" is your "iteration", etc.

So, Product Owners of the world, does this article ring true with you? How does your experience match up to Stevens' advice?

• Older >