Note: This is the first of a three part series on the critical nature of the product owner's role within the agile software enterprise. In Part I, I'll describe why 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. In Part II, Responsibilities of the Agile Product Owner in the Enterprise,  I'll provide some specific guidance for the attributes and activities of the Product Owner in this larger and more challenging, enterprise context. And finally, since staffing the Product Owner role in the emerging agile enterprise creates its own set of issues, I'll provide some case studies of how real enterprises are addressing this challenge in Part III, Seeding the Agile Product Owner in the Enterprise.

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, lighter weight governance models, 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, Part I of this series, 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 wonderful invention of the role of the Product Owner. As defined by Schwaber [2007], 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."

Figure 1 - Product Owner and the Scrum team SEQ Figure \* ARABIC

But the Product Owner's responsibilities don't end there. At the same time, the Product Owner is a resident of the ideal Scrum [1] team as the Figure 1 illustrates.

It can be seen in the figure and as follows in support of Agile Manifesto Principle #4 - (Business people and developers must work together daily throughout the project[2]), 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 hoped for organizational efficiencies, I've tried larger agile teams in the enterprise and frankly, it didn'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 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 (or iteration)
• Prioritizing and maintaining the backlog
• Participating in the Sprint planning meeting
• Elaborating stories on a just in time basis with the team
• Accepting stories into the baseline
• Accepting the Sprint
• 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 [3]; 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 [4], 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 from the Cranky Product Manager blog below [5]. 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.

Plan C—A Dual Role Approach
With Plan C, enterprises take a more refined approach, which supports dual roles of Agile Product Manager and Agile Product Owner as follows:

• The more market (customer) facing Product Managers continue in their role along with most of their existing responsibilities, but they also evolves to a far more agile set of practices, including taking on a tighter relationship with the development teams ( via a “fat dotted line relationship” to the Agile Product Owner) and engaging more directly in release planning content and validation..
• The product (technology) facing Product Owner role is assumed by either a) more technically inclined Product Managers; or more typically b) development team members who are interested and best suited for Responsibility 2. They assume the stated agile responsibilities but also take on a tighter relationship with Product Management (the fat dotted line we described above). A side benefit of this approach is that itempowers the development team to take additional control of their destiny. I also provides a new career path for those team members who would like to "grab hold of the steering wheel" in the increasingly agile enterprise.

The Name Game - Experimenting with Roles and Titles
In the prospective agile enterprise, it doesn’t usually take very long for the loaded role/title and implied responsibilities of a new “Product Owner” to portent a major crisis. Indeed, it can even be such a sensitive matter that the agile adoption can be seriously endangered by the potential conflict in role, title and responsibilities, so serious caution is warranted!

One way to address this problem is by changing the title of the person assuming Responsibilities 2. For example In a couple of instances, the role of agile Product Owner was assumed by the existing role and title of the business systems analyst, who already had most of those responsibilities and had even already been relocated to be collocated with the newly formed agile teams. In other cases, the historical title of requirements analyst was assigned to the role. In still others [6], a new title/role of requirements architect was invented, primarily to avoid conflict with existing titles role and responsibilities.

Of course, none of these titles fit every context perfectly and in most enterprises changing the title of Product Owner is more trouble than it's worth, since it isn't reflected in industry literature or on the standard trainings available. Even then, some confusion can result. Even then, some ongoing confusion is likely to result. For example, Keith Black, who as VP Product Development at TradeStation Technologies is driving a comprehensive agile initiative, recently described the problem to me this way:

"we've clearly found that the role of PO is NOT a PM. In fact, this has led to difficulty in us even describing the position in help wanted ads. If you run an ad for Product Owner you get responses from people that want to be a Business Owner. If you run the ad for PM's you get traditional PM's that are not technical. We could call the role "Analyst" or "Requirements Analyst", but that attracts more of a Systems Analyst profile. And given the fact that there's a void in the PO role in the Scrum world, it creates a situation where no-one is out there who understands what the title means."

So for many enterprises, the titles of agile Product Manager and agile Product Owner are adopted, but with the refined set of responsibilities we have described here.

Dual Roles in The Big Picture
There are other necessary changes and extensions to basic agile practices as the Agile Enterprise Big Picture [7] graphic in Figure 2 indicates.

While the details of this agile enterprise model are outside the scope of this whitepaper, a few relevant highlights in the Big Picture model include:

• Development of large scale systems is accomplished via multiple teams in a synchronized "Agile Release Train" ; a standard cadence of time-boxed iterations and releases.
• Releases (or at least Potentially Shippable Increments) are frequent, typically at 60-120 day maximum boundaries.
• Releases are developed in short (typically two week) iterations (or Sprints in Scrum).
• The dual roles for the agile Product Manager and agile Product Owner are explici
• There is a separation of product definition responsibilities (and people) at the project, program and portfoliolevels. Product Managers tend to operate at the Program Level, providing vision that drives a significant number (5-10-20 and more) of agile teams. Their “currency” of system behavioral description is most typically Features. Product Owners live at work with the teams at the Project level. They work with only one (two is also fairly common) teams typically. Their “currency “of system behavioral description is User Stories.
• Differing requirements artifacts - Stories, Features, and Epics - are used to describe the system at these different levels.

Agile Product Manager and Agile Product Owner Responsibilities
As is highlighted in the Big Picture and as I've indicated here, we see two differentiated roles-one for the agile Product Owner and another for the agile Product Manager -in the enterprise. Generally, the macro responsibilities for these roles fall as follows. 

Table 1- Responsibilities of the Agile Product Manager and Agile Product Owner in the Enterprise SEQ Table \* ARABIC

Summary
In this article, we've describe a more nuanced approach to the role of the agile Product Owner in the enterprise setting, concluding that the enterprise is likely to need both agile Product Owners and agile Product Managers to achieve success with these innovative and more productive new methods. In the next article, I'll describe some the key attributes and responsibilities of the agile, enterprise, Product Owner along with some tips for building a successful collaboration across this new APO and APM team of teams.

Bibliography

Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. New York: Addison Wesley Professional, 2007.

Schwaber, Ken. The Enterprise and Scrum. Redmond Washington: Microsoft Press, 2007.

References

1 Slide Courtesy of Trailridge Consulting Certified Scrum Course

2 Agile Manifesto, http://agilemanifesto.org/

4 http://www.enthiosys.com/insights-tools/pm-prod-owner/

5 “You 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. .” http://crankypm.com/category/agile-scrum/

6 See BMC case Study at http://www.rallydev.com/company/customers/case_studies/bmc_software/

7 See Leffingwell’s “Big Picture” blog Series at scalingsoftwareagilityblog.com

About the Author: Dean Leffingwell is an entrepreneur, executive, consultant and technical author who provides product strategy and enterprise-scale agility coaching to large software enterprises. Mr. Leffingwell has served as chief methodologist to Rally Software and formerly served as Vice President of Rational Software, now IBM's Rational Division, where he was responsible for the RUP. He was also the founder and CEO of Requisite, Inc., makers of RequisitePro. His latest book is Scaling Software Agility: Best Practices for Large Enterprise and heis also the lead author of the text: Managing Software Requirements: First and Second Editions, both from Addison-Wesley. He can be reached through his blog at http://www.scalingsoftwareagility.wordpress.com.