Product-Owner: Are you a chicken?

March 2, 2009 by Peter Stevens

Picture courtesy of Kevin Hutchinson@Flickr

One key to success in any development project is the collaboration between the customer and the team. As Product Owner, you are either the customer or the conduit to the customer. Your job is to guide the development effort to a successful conclusion. No one on the team is pulled in more directions at once than you are. You want your team to work effectively. You want your team to build the right product.

You must allocate the right amount of your time between team, customers, management and other duties. Are you spending enough time with the team? How much time is enough? Does the team even want you to be present at their meetings? If not, why not? And what are the implications of not spending enough time with your team? Three suggestions for better collaboration with the team.

The role of the product owner has been the subject of some controversy. My own experience indicates that the closer the product owner cooperates with the team, the more effective the team will be and the better the resulting product will be.

Pig or Chicken?

The chicken and pig metaphor refers to a somewhat macabre joke - ‘What is the difference between ham and eggs?’ ‘The hen is involved, the pig is committed.’ Pigs have only one goal, the successful completion of the project. Chickens have other priorities and generally have power and influence, so their ability to disturb the project is considerable. Scrum makes the chicken’s impact visible and seeks to protect the project from their influence.

Cartoon courtesy of Mike Vizdos

According to the book, the Product Owner is a pig, committed to the project and judged on the results, but no Scrum role is faced with more conflicting priorities than the P-O. The Product Owner divides his time between customer contact, managing stakeholders, and supplying the team with information to continue their work. The Product Owner may have other duties, especially if he is a customer or in management.

The Product Owner is usually a true pig

One litmus test of the quality of the relationship between product owner and team is whether the Product Owner is present and allowed to speak at the retrospectives. I ran a poll on this topic: Only 16% of the respondents claimed that the P-O was never present. 70% of the respondents claimed that the Product Owner was always present. Nobody claimed that the P-O was required to keep silent.

Impact of a poor Product Owner

What impact do deficiencies in the Product Owner cause? Insufficient or delayed information will impact team performance. Rework, poor or non-existent estimates, and stories which cannot be accepted at the end of the sprint are all typical symptoms of inadequate contact with the product owner. It all translates to an inability to finish the committed sprint backlog.

More subtle but more damaging to the project is poor morale caused by a P-O who shows that he doesn’t care. If he doesn’t care, why should I? And people lose their sense of urgency.

When should the Product Owner be a chicken?

The main reasons for keeping the product owner at bay are fear of the product owner or accommodating a product owner who is not willing or able to change.

The beauty of Scrum is that projects can function effectively in a wide range of contexts. My first Scrum project had (initially) a very difficult relationship between P-O (who was a paying customer) and the team. We started with very strict rules about when and how much he was allowed to speak. As the project continued, and the trust improved, we were able to relax these rules to the advantage of the project. Eventually "the team" referred to the entire Scrum team (including the P-O), not just the Implementation team.

Warning signs

The Chicken Test

If it walks like chicken and clucks like a chicken, it probably is a chicken. And if the team is treating you like a chicken, then you are probably acting like a chicken. For example, your team does not want you at the daily scrums or retrospectives or insists that you not be allowed to talk if you do come. Something in your behavior is probably making them uncomfortable.

Failed Sprints, inability to release

A further warning sign is an inability of the implementation team is to accomplish the sprint goals or release goals. The team complains about the quality of the product backlog. Your actions are cited as a reason that the team cannot make its commitments. There may be other causes, but stories which are not properly prepared, are too big, poorly understood, or do not have acceptance criteria can usually be traced back to problems in collaboration with the product owner.

Who is in charge?

If you share the Product Owner role, sooner or later your partner will make one decision and you independently make a conflicting decision. What should the team do? I have seen a release delayed at least 6 weeks due to this problem. Anything which slows the decision making process slows the project down.

Your team is demotivated

Your presence signals your priorities. If you take vacations or business trips at critical moments, you send a clear message about your priorities to your team. If you only see the team members at the scrum planning and review meetings, then the information flow is surely inadequate and you will see the symptoms mentioned above.

Three tips for being a better product owner

It is possible to guide a project to a successful conclusion even if you are a ‘distant’ product owner, but it is more difficult. Here are three suggestions for better information flow between you and your 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.

Scrum management is empirical management

Managing a project is always about the art of the possible. Start with your best effort and improve continuously from there. With this attitude, you will naturally tend toward the right relationship with your team.

Permalink