Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 148 posts at DZone. You can read more from them at their website. View Full User Profile

Product Owners in Practice

  • submit to reddit
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.
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Paul Russel replied on Sun, 2012/06/10 - 5:41am

If you get the fundamental stuff straight… good daily stand-up meetings usually follow.”
Can’t agree more. In one of my first teams that followed Scrum, there was a lot of scepticism (naturally) at the new set of meetings (daily scrum, review/retro, sprint planning etc.) and there was also a sort of inertia, that made people to *not* collaborate. I can’t explain it, it was frustrating. It took a while for things to fall into place, but when it did, it was a giant leap.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.