When I am having trouble with a product or a service, I will contact customer support and expect that my problem is taken care of. Businesses, who truly care about their customers, ensures that the customer gets an answer right away or the customer support will contact the customer after they have figured out the answer.
Unfortunately, sometimes I notice that I am being bounced from person to person and no one seems to know the answer I am looking for. This kind of experience makes me really annoyed. In fact, it makes me want to scream. I am sure that you have had similar experience as well and you know how frustrating it is. This makes me wonder:
If every one of us knows how annoying it is to be in this situation, why so many agile software projects are suffering from the same problem?
The answer to my question is simple. Either a product owner has not been assigned to the project or the product owner is not committed to the project. Your current project is probably in this situation if
Team members must contact more than one person to get an answer to their product related questions. In this situation team members are spending their time figuring out how the software should work instead of implementing the wanted features. It should be clear to anyone that this lowers the productivity of the team.
Team members might also try to guess how the implemented software should work. This will probably decrease the productivity of the team, because their guesses cannot always be right and they have to implement some of the features twice.
A third problem is that this degrades the ownership of the product. In the worst case team members transfer the ownership of the product to a person, who is willing to answer their questions. This is (or at least it should be) considered as a serious problem, because the official product owner is responsible of the project’s outcome; The shadow product owner is not! Remember, ownership is not a floating point number. It is a boolean; You either have it or not (Thank you Russ Miles).
The priorities of the product backlog items are not clear. If the priorities are not clear, team members do not know which features they should implement first. This is a problem, because they have to either waste their time to find it out or use their own judgement when deciding what to do next.
The first case lowers the productivity of team, because the team members cannot figure out the priorities of the features and implement the features at the same time. The second case might lead in to a situation where “nice to have” features are implement before “must have” features, because team members are not often domain experts. That is why the product owner must communicate with the team and inform them which features are important and which are not.
Team gets no or very little feedback from their activities. Continuous improvement is one the most important principles of Agile software development. Constant feedback is an important tool for supporting continuous improvement, because it guides the future actions of the team. The project team cannot fix a problem if they are not aware that it exists. It is true that an active and motivated team can probably figure out some improvements, but those improvements are not probably related to the product in a any way. Also, it is quite important to understand that most of the people want to have some kind of feedback from their work. If no feedback is given, it might lower their motivation. This will probably decrease the productivity of the project team and decrease the number of improvements suggested by team members.
I have now described to you some of the characteristics and consequences of a situation, where the product owner of a software project is absent. The reasons of one’s absence are irrelevant. The fact is that each software project must have one (and only one) product owner. I admit that I do not have a definite answer to a question: how to be a good product owner, but I can tell to you what kind of product owner I would like to have.
I would like to have a product owner, who
- Claims the ownership of the product and guides the team members to do the right things.
- Ensures that the features of the product are implemented at the right order.
- Motivates and guides the team members by giving them feedback (both good and bad) from their work
PS. Scrum Alliance has published a good article, which describes how one can be a good product owner. You might want to check it out as well.