Although much of the agile literature and many of the agile implementations center around the development team, perhaps not enough attention has been given to the product owner.

How can a product owner, even an otherwise good product owner, impair the success of the agile team?

 

- Not knowing the full extent of what needs to be done to complete a feature or system and therefore not including necessary items on the backlog

- Knowing the product, but not being able to communicate that knowledge well enough to the developers

- Not being able to devote the necessary time (for many projects this means nearly full time) to the product being developed and therefore not being available to answer the team’s questions

- Lacking a clear vision about the whole product and/or many parts of it (for example, the user interface)

- Failure to include the entire business community which has a stake in the outcome of the product in the decisions for the development of the product

- Letting the team dictate the outcome of the product and having it rejected by the user community

While such failures may not be attributed to the development team, it may still be considered a failure of Agile.

There is an irony here. One of the reasons that Schwaber and Southerland eliminated the project manager from Scrum and replaced that role with the Scrum Master and Product Owner was that they felt the responsibilities of the project manager were too great for a single role. The split of the role into the two Scrum roles was a good idea, dividing the project manager into the “soft” team coaching type functions for the Scrum Master and the “hard”, authority-driven parts of the role to the product owner. The problem is that in reality the product owner’s responsibilities have gone beyond those of the typical PMBOK® Guide project manager. (The Scrum Master’s responsibilities have as well, but that’s a different discussion).

As a former programmer (developer in today’s terms), who has been subject to multiple business managers and others telling me what they wanted and when at the same time, I applaud the concept of “one neck to wring” which limits the business authority over the team of developers to only one voice. However, in practice this means that the product owner must be an interface between all the business people requiring input to a particular feature or function or system, all those business constituents who may be impacted by changes being made, and the development team as well. In the past, this might be a job for the business analyst—full time. But since the business analyst as a role has been eliminated from Scrum and therefore most of Agile, it falls on the product owner to do it. And the product owner, according to Scrum, is supposed to be part time, working in the business area to be sure that the product owner understands the business rationale behind the items on the product backlog. (This particular aspect differentiates Scrum from Extreme Programming (XP) which demands that the business representative (called the On Site Customer) be devoted not only 100% to the project, but physically co-located with the team for the duration.)

What is the typical product owner expected to do?

  • Negotiate and mediate among the affected business units
  • Deal with individual business constituents and their idiosyncratic requirements
  • Build and maintain or “groom” the product backlog and be able to explain in detail every single item
  • Be responsible for the prioritization and ultimate delivery of the product which includes release planning
  • Maintain positive relationships with the members of the development team
  • Review and comment on the product in progress every two weeks
  • Be available to answer questions from any member of the development team at any time
  • Attend the various ceremonies of Scrum at the team’s request
  • Provide motivation and vision to the development team to spur them on
  • Provide management with progress and other status about the product

All while still doing their primary job for which they were hired. Oh, yes, and take the blame from the development team for poor backlog items and just about anything else that gets in the way. (I have seen the product owner listed as an “impediment” so many times that I think that removing the product owner will remove all the “impediments” to success for any given team).

Ivar Jacobson calls the product owner “the single indispensable person on the project, without whom nothing can be done”, but also calls the product owner an “Achilles Heel”. Ken Schwaber reminds us that “Scrum does not define … what the Product Owner should do.” Schwaber goes on to say, “Delegation of product owner responsibilities continues the deep divide between development and its customers.”

The product owner was designed from the developer’s point of view to help the development understand what the business wants so that the development team can produce a valuable product. As such, the product owner definition is skewed to a developer perspective while being defined from a business perspective. This, of course, can create as big an issue as the issue it was created to solve.

How do you define the product owner on your teams? Does the product owner have all the responsibilities listed above? If not, who does have them? We’ll talk more of the role of product owner in upcoming articles.

PMBOK Guide® is a registered mark of the Project Management Institute, Inc.

 

 

One comment

Leave a Reply

Your email address will not be published.