From Clouds by Joni Mitchell
I've looked at life from both sides now
From win and lose and still somehow
It's life's illusions I recall
I really don't know life at all
My experience has been that the product owner role is the one most likely to be problematic in an organization undergoing an agile transformation. The courses and books describe the product owner as “single throat to choke” or as “the person who represents the stakeholder community to the product delivery team.” Yet among the three scrum roles - product owner, scrum master, and team member - the role of product owner is often the most difficult to fill properly and perform as defined. In this blog series, I'd like to offer some possible reasons why that is so, how some mitigate the challenge, and what happens when we keep striving to get it right.
Why the Role of the Product Owner Is Difficult
I believe one reason why the product owner job is so problematic, especially in an organization that is in the early stages of agile transformation, is that the bulk of the organization outside the scrum team, particularly the middle and senior managers, all pretty much still operate in a hierarchical, functional organization. The product owner operates at the friction point between the agile team and the rest of the enterprise. There are multiple layers of management with each one believing they are responsible for an aspect of the endeavor, and each wants to influence and understand what is going on via their traditional mechanisms.
How These Challenges Manifest Themselves
To illustrate this situation, I’ll share a few stories. Do any of these sound familiar?
I was once part of an effort where the CIO for a large government agency declared that he would be the product owner for a new effort to automate a business process. The support by the CIO was laudable; he clearly wanted to send a message that the agile effort was important but, unfortunately, it was not an effort he could sustain. After a few months he had to drop out and the teams had to recycle through the Tuckerman stages of team development (forming, norming, storming) all over again when they should have been reaching cruising altitude. It would have been preferable if the CIO had used his influence to hand-pick a sustainable product owner and work towards a change in the policies and procedures of the organization to establish the “product owner” as a standard job title.
In another organization the people suited to the job of product owner had positions that involved keeping the business running. They had day jobs that involved keeping planes in the air and the product moving. This organization faced a lot of stress due to changing business conditions and their resources were tight. The business stakeholders would say, “We need to take care of business - you should know what to build.” The IT people would respond, “Yes, but we need your expertise with the hundreds of business rules that we don't know.”
Additionally, the business people had no incentive for stepping up to the role of product owner and assuming the risk associated with a product development effort that might not be a success, especially as an extracurricular activity. The business side viewed at the agile ceremonies, such as the sprint reviews and daily stand ups, as big time commitment that they could not afford. And so, the IT team responded with the slightly veiled threat that if they ended up building the wrong thing it would cost a lot more to run the business. Clearly, this was not a productive situation.
A healthier response to such a dynamic is for scrum master and agile coach to respond with, “Help us help you.” If we can only get things moving and start delivering value that saves you time we will be able to build upon that and improve our partnership. Senior leadership needs to recognize that it takes energy and resources to make a change and one of those changes involves a more intimate integration of our business and IT functions.
What Is an Activity of the Product Owner?
In the meantime, the other members of the agile team must carefully consider when and how the product owner is engaged with the team. The coach or scrum master may ask, “How many hours per week can you give us?” From there, they can prioritize how the product owner’s time is spent. They may determine that the time is really needed for items such as:
- Prioritization of the back log at the beginning of the release
- Backlog grooming sessions for an hour twice per week
- Sprint reviews (with the option to send a delegate empowered to approve on his/her behalf)
- Attend 1 or 2 stand-ups each sprint even if he/she can't make all of them
- Review the scrum board from time to time
Now that we have addressed the challenges commonly faced within organizations and how we can begin to overcome them, our next post will look at various ways to mitigate them.
Are you currently working through product owner challenges? We are here to help! Explore our Agile consulting services, or contact us at: agileinfo@eliassen.com.
