Overview: Scrum Masters and Developers may complain about Product Owners but viewing them as partners rather than adversaries and collaborating with them can help ensure success.
“My product owner is awful!”
Does that sound scandalous? A mean and unreasonable statement? Or is it a universal issue plaguing every single Development Team all over the world?
Participate in any Agile workshop, scrum team discussion, retrospective, or any lunch or elevator chat and I guarantee someone will mention how and where their Product Owner/Manager is lacking. It is frustrating and a common pain point for many teams.
Scrum has three main roles: Product Owner (PO), Scrum Master, and the Development Team. While some organizations might not use these exact job titles, the responsibilities of each role are very clear and vital to the success of the team as a whole. Having an “awful” one third of the team, therefore, is a serious matter!
An Evolving View of Product Owners
A long time ago, somewhere near the beginning of my career, as an Agile team member, I was good at my exact role and really didn’t care much about any process (or anything else to be frank). I got some cards assigned to me at the beginning of the sprint, I did them well & within the timeframe—all was good. I honestly never interacted with my PO and I still don’t even know or remember who they were. I had zero need for them, so I didn’t seek them out and had no need to analyze their role/participation in my sprint work.
Sometime later, I found myself in a progressive atmosphere where I willingly sought more responsibilities and took greater interest in my work. I needed help with a specific task and was asked to reach out to my PO because they were considered to be the SME for that topic! So, I reached out, got the help I needed and was amazed at the depth of knowledge my PO possessed and how I was able to harness that knowledge to be better at my own job. It was like discovering a new tool or technology I could use to become more efficient in fulfilling my responsibilities.
With time I found myself progressing on my journey to total Agility and my responsibilities changed drastically. I needed more help, had questions that needed a prediction of the future, greater insight into the product, and so on. I reached out to my PO and expected to get all the information on tap and on demand. I was surprised when they said they did not have the answers I needed! Imagine that—a PO who does not know it all! After I recovered from that shock, I insisted they accompany me as we reached out to someone else who gave us the knowledge which we sought.
It was strange because up until then a PO was like a drive-through window for me; I drove up, asked for information, got it, and left. It was quite a one-way exchange. I had never viewed a PO as a true team member, someone who could also be a “seeker” of information and not always the “source.” I guess in many ways I learned that sometimes even the best tools need driver upgrades and maintenance in order to stay current and efficient. The PO does not always know! But they can help you get the answers you need.
The Product Owner Is Your Partner
As my engagement with my product deepens and my needs change, I find myself even more involved with my PO. But this time around, I treat them like a partner, not just a resource. I feel I am, without holding any grudges, as much responsible in helping them achieve knowledge and insight as they are in giving my team vision and clarity to succeed in our joint quest for a quality product.
I text, email, call, send meeting invites, reminders, and Jira comments. If there is a mode of communication that is available and HR-approved, you can bet I use that to communicate with my PO. I insist we meet and plan agendas before involving the entire team in technical discussions. I maintain transparency & honesty by clearly sharing details pertaining to team capacity and resource availability. I also remind, confirm, request, and follow up as needed. My PO is a team member as well, and I don’t think I can achieve success without ensuring each team member has everything they need in order to be successful in their role. Success is ensured by working together, not blaming each other.
I do continue to push back on unreasonable demands, scope creep, and conflicting priorities, and my PO still schedules a weekly meeting where we review missed or delayed sprint commitments, team issues etc. But, whatever we do, we do it together as a team and with an understanding that we need to help each other in fulfilling our responsibilities so that the Development Team has a distraction-free and productive sprint. And while things are not always ideal, no one is being truly “awful.”
This post originally appeared on LinkedIn.
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.
See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.
