Product Owners in Practice
At the risk of being accused of bashing Scrum for the second time this week, I want to talk a little about the Product Owner role. What I want to explore a bit is why the Product Owner is such an important construct in Scrum… and furthermore, why it is difficult for so many organizations to really fill it well.
The Product Owner is the person responsible for determining what the team is going to build. This is an important construct in Scrum because it unifies the voice of the business for the team. The Product Owner gives the team unambiguous direction and ensures they don’t have to worry about conflicting business priorities.
As a community, we seem to be backing away from the idea of a Product Owner as the single wringable neck… but that’s really the whole point, isn’t it? We need to have ONE person that is RESPONSIBLE for telling the team what to build. Without it, how are we sure we are building the right product? How do we know the person defining the backlog can singularly and authoritatively guide the output of the team?
In reality though, how often does one person really own a product? If there really is one person that owns the product, how often does that person have time to sit full time with the team? Is it realistic to ask the real Product Owner serve as Product Manager, Project Manager, and Analyst? Is it realistic we can have one person own the vision and guide the execution in any but the most trivial of organizations?
As Scrum goes more mainstream, there seems to be acknowledgement that most of the time, we have multiple people filling the role, most of whom are merely proxies for the real decision makers. If this has become the norm, if we don’t have a single authoritative voice to guide the team, if we don’t have a single person that decides what to build, what is the point of having a role called Product Owner anyway?
I wonder if most of us are even honoring the basic principles behind why the Product Owner role was created in the first place? Are we bending Scrum because the demands it places on us are just too great?
So again, I find myself asking questions like… if the PO doesn’t really OWN the product, are we bending Scrum past it’s acceptable limits? If we have several stakeholders in a PO team, are we doing Scrum-but? Do I REALLY have to empower a SINGLE person to be ACCOUNTABLE for telling the team what to build? If I don’t am I really doing Scrum? Where are the limits? What defines acceptable adaptation?
So… I think what is nagging me here is a growing dissonance between what you might call textbook Scrum, and Scrum as practiced in most organizations, by most people I talk with. I don’t want to bash Scrum, I want to reconcile how we teach it, how we certify it, with how it is generally practiced. And by all means, if we are going to certify these adaptations, I’d like to see us start including them in our body of knowledge, however lightweight or informal.
Comments (10)
David Hawks
I agree the PO role is one of the hardest to get in place and successful. I would have to say that I have yet to accomplish the task of getting this role implemented in a way that I feel was highly successful. I think one of the issues is that it maybe doesn't replace any traditional roles in the organization, but is a totally new full time role. It is hard to get additional headcount approval for this role and even if you can, finding the perfect candidate can prove even more difficult.
http://www.austinagile.com
Alex
David is right. The problem is the mapping of traditional roles to the Scrum roles. It's a lack of commitment resulting in a half-backed transition to Scrum; customers are kept separate from the team and business analysts are forced to do the translations. And of course, the BA isn't a role of product responsibility. In the meantime, Project Managers are styled as ScrumMasters, yet acting as decision makers for the BAs.
Mike Cottmeyer
David,
I think I might agree with you. Here is the question, are we bending Scrum, are we setting ourselves up for failure, if we don't get this headcount approved? Can we be successful with a proxy, non-accountable Product Owner?
Tough questions!
Craig Brown
Mike
OGC came up with a report last year about the poor performance of project sponsors and "Senior Responsible Owners."
The single source of truth is critical for significant projects. Large budget and schedule over-runs mainly come from indecision and lack of timely feedback.
Whether you are consultative, have a team of analyst assistants, service 'internal customers' or whatever, the issue is one vision and availability.
Look beyond the details and check whether there is someone who is (1) accountable for outcomes and is (2) engaged in the work of the project team?
Got them? Good for you.
Next challenge: do they have suitable authority?
Josh
Very thought-provoking Mike. It seems to me the role of the product owner gets glossed over in practice quite a bit.
Jim Kinter wrote a great post that is kind of a case study about how they do Scrum in his world.
http://pmstudent.com/chaos-and-scrum/
I see things I like in Jim's description such as "the expectations of what it means to be a Product Owner are communicated loudly and often" which I like, but I'm not sure the PO is a dedicated role either with an additional headcount associated.
I'd be interested to see your insight on what Jim laid out, Mike.
Mike Cottmeyer
Hi Josh,
Read the post, thanks for the reference.
What made Jim's situation work was that there was a single team and a well defined PO for each. If the POs were in conflict, there was a council in place to resolve the conflict. That seems a pretty straightforward and reasonable adaptation (or enhancement) to Scrum.
I would have liked to see what Jim had to say about the nature of the expectations he was communicating 'loudly and often'. That is more to the nut of what I am writing about, what ARE we asking Jim's POs to do?
I also think that Jim's environment was well aligned and setup to be successful. Single team, multiple products, clear way of resolving conflict. The more interesting, and admittedly dysfunctional scenario, is when you have 15 teams responsible for working on a suite of products.
It is not just a matter of resolving capacity and prioritization issues, it is a matter of resolving dependencies across products in the product line. What about when a business unit needs to bring a feature to market that spans all the products in the suite… that's fun stuff to work through.
Anytime you have a small company, small team, and localized decision making, you can make Scrum work with minor adaptations. The challenge is in larger organizations solving larger more complex problems… you need to add more to Scrum. I would just like to see us have more conversation as a community on what those acceptable large scale adaptations are, and have the community weigh in on if they are Scrum-but or not.
More problem solving, less finger pointing. And I keep going back to this… if we are going to 'certify' people in these practices, rather than just train them, I think they need to be written down somewhere. I think we need more conversation on what we are certifying.
Thanks again for the comment.
David Morris
Most situations where I've worked on projects based around developing or enhancing websites, I have had a group of product managers, all of them with an interest in pushing the limits on the value they can achieve through changes to the site/portal, and none of them wanting a single colleague to have the deciding role.
However it's really important that the delivery team do not have multiple voices pushing them this and that way. That would undermine the productivity advantages of scrum.
So, what options do we have?
* force them to 'elect' one colleague as PO?
* somehow act as a hive-PO?
* escalate and get their manager to act as PO?
* have someone act as proxy-PO on their behalf?
Invariably it's the last of these, and typically a business analyst who has to take on this role.
Of course, the limits of what decisions the proxy can take have to be established, and this can easily be mitigated by having frequent touchline conferences (going with the rugby metaphor).
Mike Cottmeyer
Thanks for the comment David. I agree that these are not impossible risks to mitigate. I have also seen scenarios where the BA get starved for information because the POs either won't take the time or can't seem to agree with each other. Healthy organizations have more options than unhealthy ones.
Mike Cottmeyer
Craig,
I agree with you and have made the PO role work in any number of ways. have worked with teams that were told they were not successful, or doing Scrum-But because they did not implement the PO role by the book. I feel like there is a growing dissonance between Scrum in theory and Scrum in practice.
As a coach and consultant, I am okay with that dissonance, but I get really hacked off when people get accused of not doing Scrum right. We have to go in and solve the core problem of accountability and decision making, not got out and hire a bunch of product owners.
Mike Cottmeyer
Alex… but if we don't repurpose people, what do we do with them?