In speaking with a potential client the other day, it occurred to me how misunderstood the role of the product owner (sometimes also known as product manager, business owner, or customer) often is. The conversation centered around their admission that a previous attempt to adopt Agile methods had been a failure. To my delight, they were not content to cling to the often misaligned and unsubstantiated view that "Agile doesn't work here!".
As we talked, several red flags were raised that they were not aware of themselves, namely "we had too much scope creep" and "requirements weren't detailed enough". While I raised awareness to these red flags, the one that struck me the most was the comment that "our product owner wears about 9 different hats". As we approach the 10 year anniversary of the signing of the Agile Manifesto, why have we not learned that the role of the customer, often played by the product owner or product manager, is central to the success of Agile projects? It reminds me that we still have a long way to go and a lot of educating to do.
While a good Agile product owner has many traits, I like to think the best and most successful are like a great bond, and have a AAA rating. For product owners, the triple A rating means Available, Attentive, and Amiable. I have defined each word below and encourage you to remind your team, especially the person in the product owner role, and those in your organization of their importance.
The product owner is always available. Critical to the success of any Agile project, the product owner puts a priority on making them self available to the team. After all, if they are not available to the team, how can the team make sure they are doing the right work. In my experience, the organization often demands that the product owner wear many hats as my potential client observed. This problem is often an educational issue on the part of the manager that the product owner reports too and can be remedied by having a discussion with both parties.
The product owner is always attentive. Critical to the success of any Agile project, the product owner handles issues, questions, and the like, expeditiously. They don't let things lag or go unattended for an unreasonable period of time. If you can imagine a two week long iteration where a product owner lets an issue lag by a couple of days, let alone a few hours, then that lack of attention puts the team at risk of not delivering within the iteration. Attentiveness also assumes empowerment. An argument could be made that empowerment is a characteristic in it's own right, but without empowerment, a product owner is worthless. They are not able to resolve issues for the team within an acceptable time frame because they will waste a lot of time checking and double checking. So, I lump empowerment with attentiveness for that reason. This problem is often an education issue on the part of the product owner and can be remedied with the product owner.
Lastly, the product owner is always amiable. Critical to the success of any Agile project, the product owner works with the development team to achieve the best outcome possible. Certainly a friendly disposition helps, but even more important is the willingness to listen to and accept the suggestions of other team members. My experience with amiable product owners has been that they often have the best relationships with development teams by sharing a camaraderie that less amiable product owners fail to achieve. Development teams are often willing to work harder and go the extra distance for the amiable product owner. Furthermore, there is no easy solution to the problem of a less than amiable product owner. Even with education, often this comes down to a personality trait that product owners either have or they don't. This is why I recommend that organizations pick their product owners wisely.
If the importance of the triple A product owner is not understood by the affected stakeholders and the triple A product owner does not exist on an Agile project, then yes, the Agile project and possibly the organization's Agile adoption will most likely fail. In my experience, often the benefits of adopting Agile practices are over sold and the necessary tradeoffs are under sold by many information sources. Let me say this very clearly, yes, organizations will have to give up something (such as the 9 hat product owner) in order to achieve the benefits Agile methods have to offer.