Agile Product Owner and Agile Product Manager in the Enterprise: Part 1- On Product Owners AND Product Managers

This post starts a new series on the role of the Agile Product Owner and Agile Product Manager in the Enterprise context. While I, and others, have certainly opined on this topic in this series in the past, the continuing interest, enterprise challenge and controversy (this topic gets more blog hits than any other category on this blog) around these role descriptions in the increasingly agile, larger enterprise compels me to put my thoughts forward in a more structured manner. To this end, I’m starting this new series of posts to elaborate on my experiences in the context of some of the largest software enterprises transitioning to agile methods. Unless I get distracted for some reason, I also intend to turn this series into a more readable whitepaper form longer term. In the meantime, I’ll be spewing it out in post-size chunks. This is the first chunk.

Introduction

Recently, I’ve had the opportunity to assess progress in a number of large scale agile transformations, touching hundreds and in some cases, thousands, of new agile practitioners. Most typically, these involve comprehensive Scrum training for team members along with training for some number (10-100s) of ScrumMasters. Less typically, they include training for agile product owners, some XP-like technical practices (peer review , pair programming experimentation, TDD pilots, etc) and such enterprise extensions (lean requirements, agile release train, etc.) as have been brought to these companies by enterprise agilists such as myself.

Happily, I can report three common and positive findings:

• Productivity is going up
• Time to deliver new features to the market is going down
• Morale is higher, often times MUCH higher

Not one entity I’ve encountered has any interest in returning to their former practices. So all in all, these enterprises efforts to date are an emerging success and many are now redoubling their efforts to achieve the next level of productivity and quality possible with agile methods. To achieve this, we often assess current results and accomplishments – strengths and weaknesses – and then make specific recommendations for ongoing improvement.

During this process, it strikes me that the critical role of the agile Product Owner is often near the top of the list – though unfortunately it appears most often in the “areas we need to improve” rather than on the other side of the ledger! This finding causes me to reflect on the bigger picture of the agile movement as it “crosses the chasm” to the enterprise and to record my thoughts about the nature of the Product Owner role in the enterprise, along with some specific guidance and recommendations for improving these practices.

In this post, I’ll describe why I believe software vendors need to adopt a nuanced, rather than off-the-shelf, approach to this role; one which empowers both agile Product Managers and agile Product Owners to drive the enterprise to meet its objectives.

The Product Owner in the Enterprise Context

First, it is important to note that I write this whitepaper from my own experiences in the larger enterprise context. While I have also been involved in a number of highly agile, smaller projects, it is in the context of the really large enterprise that the challenge is greatest. It is there that some of the standard, off-the-shelf Product Owner practices and trainings break down, and the otherwise successful oversimplifications that drive agile success (“what is the simplest thing that can possible work”) simply do not scale to the enterprises challenge. The principles remain the same, but the practices must be extended.

The Product Owner in Scrum

It is to Scrum that we owe the nifty invention of the role of the Product Owner. As recently defined by Schwaber [The Enterprise and Scrum], the Scrum Product Owner

“is responsible for representing the interests of everyone with a stake in the resulting project …achieves initial and ongoing funding by creating the initial requirements, return on investment objectives and release plans.”

But the Product Owner’s responsibilities don’t end there. At the same time, the Product Owner is a resident of the ideal Scrum team as Figure 1 (adapted from a Certified Scrum Course) illustrates.

Ideal Scrum Team?

It can be implied from the figure and as follows in support of Agile Manifesto Principle #4 – (Business people and developers must work together daily throughout the project), the Product Owner is ideally collocated with the team and participates daily with the team and its activities.

We also note the “7 +/- 2 members” recommendation for the ideal team.

In an attempt to achieve theoretically better  organizational efficiencies in the enterprise, I’ve tried larger agile teams  and frankly, it simply doesn’t work! So in my experience this “7 +/- 2” number is sacrosanct and stands as a respected canon within the enterprise as well as in a smaller company setting. Of course, the impact of this rule is that one of the major challenges in the enterprise is that there can be a very large number (20-50-100 and more!) of such teams required to deliver a large, cooperative application. But such is generally the problem of scale.

Further, as taught and commonly practiced, the Scrum Product Owner has additional, tactical activities that directly contribute to the team’s success. These include:

• Setting objectives for the Sprint (iteration)
• Prioritizing and maintaining the backlog
• Participating in the Iteration planning meeting
• Elaborating stories on a just in time basis with the team
• Accepting stories into the baseline
• Accepting the Iteration
• Driving release planning

Given this set of responsibilities, it is clear why the Product Owner is such a critical role in the agile project. However, the scope of the problem in the enterprise is daunting because we have just identified 20-50-100 new roles that have to be filled in order to execute agile successfully. Given this context, it should come as no surprise that “enhance capabilities in the critical Product Owner role” often makes it to near the top of the enterprises ongoing improvement recommendation list!

The Conundrum – Why the Enterprise Product Manager is Likely NOT the Agile Product Owner

In summary, there are two primary responsibilities that can be derived from the above:

Responsibility 1 – The Scrum Product Owner sets the vision, product objectives and manages to ROI

Responsibility 2 – The Scrum Product Owner is a member of the team and works daily with developers and testers to help the team meet its Sprint objectives.

However, when agile is introduced into a true enterprise context, (most typically through Scrum team training as we described earlier) there often occurs a role and paradigm mismatch between the Scrum teachings and the existing organizations structure. Specially, the mature software product enterprise is certain to already employ Product Managers who have the requisite skills, training, and existing responsibilities for Responsibility 1, above.

They work directly with customers; their responsibilities include product definition and their reward system contains an ROI element. They are trained professionals; they know what they are doing; they have extensive domain knowledge; they already work there and they have influence and authority.

This creates a conundrum which is being addressed from both the Scrum side (though standard trainings and the relatively new “Scrum Certified Product Owner Course”) and those who represent the existing professional practices of Product Management within the ISV (Independent Software Vendor) community. In one fairly pointed article, for example, Rich Mironov of Enthyosis comments:

“Product Managers are responsible for the overall market success of their products, not just delivery of software. In the Agile world, a new title is emerging—the Product Owner—which covers a small subset of the Product Management role. While this makes sense for internal IT groups that have traditionally gone without Product Management, …..agile product companies need full-fledged Product Managers to drive strategic activities and manage organizational/external participation.”

Plan A and Plan B

If we approach the enterprise in a naïve way, we might think the conundrum will be handled one of two ways:

Plan A) – The Product Manager will assume the role of the Product Owner and add responsibility 2) to their existing responsibilities. In practice, however, this plan does not work very well:

• It doesn’t scale. There may be 30-50, or even hundreds of development teams requiring this intense tactical support and there are typically not nearly enough Product Managers to go around. (I saw one case, where, prior to agile 400 developers were supported by six Product Managers).
• Product Managers may be ill suited, ill inclined and downright uninterested in these responsibilities. After all, if Product Managers wanted to live with development, they probably wouldn’t have picked their chosen path! (For those with a thicker skin, see the footnote (1) below from the Cranky Product Manager blog below. But Remember, it does say “cranky”)
• Effective Product Managers often have insufficient technical depth and inclination to add significant value to the team’s highly technical language, activities and responsibilities.

Plan B) – The Product Owners on the agile teams will now assume some or all of the prior role and responsibilities of the Product Managers. This plan doesn’t work well either:

• Why would existing Product Managers want to give up any of their influence, authority and contribution to these new agile types?
• Where would these new Product Owners come from? Hire them from outside, where they are likely to have less domain expertise than the existing Product Managers?

Experience has shown that neither of these paths is particularly effective and a more nuanced, Plan C approach, is required. But as this post is already way too long, that will have to wait for the next post, which I hope to be able to push later this week.

======================================

Footnote 1: ” (some) argue that in Scrum the product manager is the same as the Product Owner, and therefore the Cranky Product Manager needs to be constantly available to the team in order to make on-the-spot decisions within minutes of the asking.  Ergo, you demand the Cranky Product Manager sit in that sticky-note-encrusted, windowless tomb with you all damn day. Uh, no way.  Not gonna happen. Why not? Because the Cranky Product Manager needs to be the Voice of the Customer and the Voice of the Market.  How is she to do that without actually VISITING some customers and prospects?  And VISITING means that she actually needs to leave the office, hop on airplanes, and fly far, far away. ” Cranky Product Manager blog.