Organizational Insights and Comments on the Agile Product Owner Role

Mike Cottmeyer (www.leadingagile.com) recently added some insightful comments on this prickly topic that I thought were worth highlighting.

I am coming to the conclusion that the Agile PO is actually three roles combined: the traditional Product Manager, the Project Manager, and the Business Analyst.…. how do we decide who is the single accountable person for the team, even when the team is small.   It seems that the Agile PO is collaboration between Product Manager, BA, and Project Manager… with maybe someone playing multiple roles. That is on a small team…. what about now at scale?  Your  PO is really a collaborative effort between a PO (and PM) structure that is likely multilevel, with each level having some combination of the three roles and maybe an enterprise architect.

This comment crisply highlights the challenge and opportunity implied by the critical and yet overloaded role of the PO in agile/Scrum. To wit:

1. The PO role is an important new construct which provides a single point of focus to the team that defines “what it is we will be building”. Eliminating the problem of conflicting inputs from multiple sources provides a) efficiency leverage for the team, b) enhanced empowerment via team-based control of  product conceptual integrity and c) a clear and unambiguous set of priorities
2. However, it also creates many problems in the process. After all, how would we expect architects, project managers, business analysts, product managers, etc. to respond to the new rule: “you no longer tell the team what to build or the details of how to implement it, that all must go through the Product owner from now on”.

Wouldn’t we expect this to cause some serious problems? Especially in the larger enterprise context where the roles (and titles) are well established, empowered, likely quite capable, and are codified in the existing HR/career development ladder? No wonder the PO challenge is so great!

However, having said all that, we should make no mistake about the fact that implementing the PO role (largely as defined in Scrum) it is the right challenge for the agile enterprise and it must be addressed for agile success.

You can see more of Mike’s thoughts on this topic at www.leadingagile.com. I’ve added his blog to my blog roll as well.

Agile Product Owner and Agile Product Manager in the Enterprise Part 3: Skills and Attributes of the Product Owner

Note: This is a part 3 of continuing series on the critical Product Owner’s role within the agile software enterprise. My primary collaborators on this series are Mauricio Zamora of CSG Systems, and Jennifer Fawcett of www.agileproductowner.com. This series, in turn, is in part an elaboration of the broader Agile Enterprise Big Picture series.

Recap of the Dual Roles

In Part 1 & Part 2, we described the critical nature of the role in achieving enterprise agility. We also described how, in the enterprise at least, the responsibilities of the agile Product Owner (as originally and primarily defined by Scrum) is more likely a set of responsibilities that are shared between a significant number of agile Product Owners (APO) and a smaller number of agile Product Managers (APM). Specifically, we described a dual set of roles as follows:

Agile Product Manager	Agile Product Owner
Market/ customer facing	Product/technology facing
Collocated & reports to marketing/business (typically)	Collocated & reports to development/technology (typically)
Focuses on market segments, portfolio, positioning and ROI	Focuses on product and implementation technology
Collaborates with Product Owners	Collaborates with Product Managers
Owns the Vision	Owns the implementation
Drives the Release	Drives the Iteration

This conclusion isn’t particularly startling when you look at some basic enterprise facts:

1. It can take a substantial number of agile teams (3-5-10 or more) to deliver meaningful end user value, for even a single new feature in a large application
2. It can take an even larger number of teams (10-20-100 or more) to deliver a release to the market

So with respect to Owning the Vision you obviously can’t have 3-5-10 Product Owners each trying to deliver their individual view of the vision of the feature to the market. Therefore the overall vision for the feature must rest in the hands of someone who has the skills, knowledge time and inclination to work directly with customers to define and validate the feature vision. In most independent software vendors (ISV), this typically rests in the hands of the Product Manager. (Note: In the IT shop, this role is often fulfilled by someone with the title of “Business Owner” or “Project Manager”. In the embedded systems world, the role may often be fulfilled by someone with the title of Product Manager, or Project or Program Manager).

With respect to Drives the Release, the problem is compounded because it can take the collaborative efforts of 10-20-100 agile project teams to deliver a release. Each Product Owner/Project Team contributes their feature, sub-feature or component, but the release itself must be under the vision and governance of a broader authority, most typically the Product Managers/Business owners who are, in turn, working with those who have responsibility for the enterprise portfolio.

So we have concluded that this separation of concerns can bring additional focus to both the vision and the implementation, and the role separation (APO and APM) can be a fairly natural fit for the larger enterprise.

Skills and Attributes of the Enterprise Product Owner

As we have said, this is a critical role in achieving enterprise agility, so the transitioning enterprise will need to find people to fill this role. In the larger enterprise, this can involve the repurposing or placement of as many as 10-20-100 individuals (one PO for every one or 2 agile teams). The primary responsibility of the PO role is to work daily with the team to define the specifics of the intended behaviors of the system and further, to help the team deliver on those expectations. In order to be effective in their role, the enterprise should look for people with four key skills and attributes:

1. Ability to communicate—the Product Owner is the “glue chip” that binds the Product Management function tightly to the development team. Doing so requires the best possible communication skills as the Product Owner translates, via the user story metaphor, user and business objectives into details suitable for implementation. Moreover, the Product Owner will almost certainly be involved in customer demos, sales support and the like, so some customer-friendly skills will enhance performance in this role.
2. Good business sense—Agile’s insane focus on value delivery also demands that Product Owners should have working knowledge of the business domain. In this way, the PO can better understand and define user stories that deliver real value to the end users and establish priorities and tradeoffs for system functionality and performance. If that is not practical, the PO must at least be inclined towards the user and business domain and in general, be a quick study who has demonstrated people skills and general business knowledge.
3. Technical foundation—effective scope triage requires the constant evaluation of technical, functional, performance and user-value tradeoffs. This, in turn, requires a reasonable degree of technical competence as well as an understanding of how it is that software is actually developed and tested. In addition, as continuous refactoring is integral to agile, prioritizing refactors and defects is important and the PO must be able to work closely with the team to assess quality and schedule impact.
4. Trust—Since the primary responsibility for prioritizing and managing the backlog (i.e. what will and will not be done) falls to this role, the most essential attribute of the Product Owner is trust. The teams have to trust the Product Owner to help them build the right thing; make the hard calls on scope triage and to defend their interest in quality and functionality. The Product Managers have to trust the Product Owner to faithfully represent their features and feature priorities to the development community.

Looking Ahead

Finding people with these skills and interests and providing them with sufficient mentoring or training is the responsibility of the management team driving the enterprise transition. To further assist in this challenge, I’ll describe the specific responsibilities and activities of the agile Product Owner in the next post. In a later post, I’ll describe some case study vignettes of how some real world enterprises successfully addressed the challenge of finding the right number and right kinds of people to successfully implement this role.

Agile Product Owner and Agile Product Manager in the Enterprise: Part 2- A Dual Role Approach

Note: This is part of a new and continuing series which is collected under the Product Owner/Product Manager category.

In the last post, Agile Product Owner and Agile Product Manager in the Enterprise: Part 1- On Product Owners AND Product Managers , I described how both of these roles and titles are likely to exist in the agile enterprise. In an attempt to avoid this apparent complexity, I described two alternate, but ineffective plans A and B.

• Plan A) – The Product Manager will assume the role of the Product Owner and add Responsibility 2) (i.e. 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) to their existing responsibilities.
• Plan B) – The Product Owners on the new agile teams will now assume some or all of the prior role and responsibilities of the Product Managers.

Experience has shown that neither of these paths is particularly effective and a more nuanced, Plan C approach, is required.

Plan C – The Dual Role Approach

With Plan C), a number of enterprises have taken 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, keeping most of their existing responsibilities. However, they also evolve a far more agile set of practices, including taking on a tighter relationship with the development team (in large part 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; and b) development team members and/or others who are interested and best suited for Responsibility 2. (Note: Since, in the enterprise, there can be a number of them (10-20-50) required; where these people come from is the subject of an upcoming post). The team members in this new role assume the fairly well defined agile PO 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 it empowers the development team to take additional control of their destiny. It can also provide 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 Product Owner role. In a couple of instances, for example, the role of agile Product Owner was assumed by the existing role and title of the business 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 yet another example, (see BMC Case study), a new title/role of requirements architect was invented, which helped clarify the role and helped avoid conflict with existing titles role and responsibilities. Of course, none of these titles fit every context perfectly and in changing the title of Product Owner is likely to be more trouble than it’s worth, since it isn’t reflected in agile literature or in the standard trainings available.

Even then, some confusion can 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 role/title of Product Manager continues and the new role of agile Product Owner is adopted, but each has a refined set of responsibilities as we have described here.

Dual Roles in the Big Picture

The dual role approach isn’t that new to this blog and has already been indicated and described in the Agile Enterprise Big Picture series and graphic as this figure indicates.

  

Agile Product Owner and Agile Product Manager in the Big Picture

While the details of the Big Picture are outside the scope of this post, (for this, see Big Picture category) a few relevant highlights include:

• 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.

Dual Roles: Differentiated Responsibilities

Within the enterprise context, we often see the two roles align as follows:

Agile Product Manager	Agile Product Owner
Market/Customer Facing	Product/Technology Facing
Collocated & Reports to Marketing/Business	Collocated and Reports to Development/Technology
Focuses on market segments, portfolio, positioning, ROI	Focuses on Product and Implementation Technology
Collaborates with Product Owner	Collaborates with Product Manager
Owns the Vision	Owns the Implementation
Drives the Release	Drives the Iteration

Summary

In these first two posts in this series, I’ve describe a more nuanced, dual role approach to the agile  Product Owner/Product Manager functions in the enterprise setting. In the next few posts, I intend to describe:

• The key attributes and day to day responsibilities of the Agile Product Owner
• Some tips for building a successful collaboration across this new APO and APM team of teams.
• How and where real agile enterprises go about finding the right people to fill these roles

And then eventually,

• How the Product Manager’s responsibilities also need to evolve in the agile enterprise

And probably some more stuff by the time I get there.

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.

More on Agile Product Managers and Product Owners

In a recent post, How to be the Ultimate Agile Product Team, Jennifer Fawcett opines on the evolving roles of agile project managers, agile product managers and agile (and traditional) product managers in a fast growing ISV/Embedded systems environment.

Like some others, Jennifer has concluded that the Product Manager role in an agile environment continues to focus primarily on mostly traditional PM responsibilities – market analysis, business case, new products and features, product roadmaps, etc. – while the new Agile Product Owner role focuses primarily on working daily with the team in support of implementation. That’s not to say that the APO doesn’t own or drive the vision for the feature or component that the team has responsibility for, rather it’s more a matter of focus (implementation (APO) vs. market needs analysis (APM) and the level of abstraction (feature or component level (APO) vs. product or system level (APM).

She described her view of the differing responsibilities in the following table.

Agile Product Manager (APM) Responsibilities	Agile Product Owner (APO) Responsibilities
Tracks industry trends	Tracks internal cadence and deliveries
Defines release objectives	Defines iteration objectives
Provides overall strategic direction	Provides day-to-day tactical direction
Delivers business level use cases or stories	Provides system level use case or story elaboration
Has a solid understanding of current solutions	Has an understanding of architectural component and subsystem design
Defines external roadmaps	Defines user acceptance tests
Manages release and portfolio priorities and backlogs	Manages the iteration and cross project priorities
Manages the changing needs of the market and customer base	Unblocks and focuses the portfolio or feature teams throughout the iteration
Manages market messaging and positioning	Defect scheduling
Provides the overall vision	Provides the implementation
Lives in Marketing	Lives in Engineering
Communicates daily with the Product Owner (shares a brain with the PO)	Communicates daily with the Product Manager (shares a brain with the PM)
Delivers The Release	Delivers The Iteration

Perhaps more importantly, she goes on to note that building an effective set of relationships between these roles requires Collaboration, Partnership and Trust. For that discussion, I refer you directly to her article.

More on Product Owner vs. Product Manager – Revenue Products need Product Managers not/and Product Owners?

As I’ve noted before, the Product Owner and Product Manager category on this blog still seems to stir the most interest amongst readers.

I just noted that the folks at enthiosys recently published the following article Revenue Products need Product Managers, not Product Owners. (The title is a tad misleading, because in point of fact and as the article points out, agile enterprise ISV’s (independent Software Vendors) generally need both). This is an excellent, summary perspective of much of what is being discussed in classes, forums and blogs as agile crosses the chasm to the enterprise. It’s a short read and pretty much on the mark. Here’s a short introduction:

“Product Managers are responsible for the overall market success of their products, not just the 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 and can lead to role confusion. Here, we’ll explain why revenue-producing products need full-fledged Agile Product Managers.”

If your organization has, or should have, Product Owners and Product Managers, you should definitely check it out.

And for more on this topic, check out the Product Owner/Product Manager category on this blog.

–Dean

Enterprise Agility-The Big Picture (9): The Agile Product Manager

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Teams, Iterations , the Agile Product Owner, Backlog, User Stories and the Iteration Backlog the Release , Vision and Release Backlog and The Roadmap. In this post, we’ll discuss the Agile Product Manager, [callout 9] below.

Big Picture 9 - Agile Product Manager

I’ve blogged off and on the “agile product manager vs. agile product owner” roles over the last few months so this is not a new topic and I won’t repeat it all here. Many of these posts are categorized under the Product owner/Product Manager category on this blog. We have also touched on the Product Manager in the Big Picture post on the Agile Product Owner and the follow on post. In addition, I described some of the basic Product Manager responsibilities in this article a few years back.

Based on blog hits and search criteria, this topic is pretty relevant right now so it’s a good time to elaborate further on the responsibilities of this role within the context of the Big Picture.

Product Manager/Business Owner/Business Analyst?

Throughout this series, I’ve used the term “Product Manager” instead of Business Owner or Business Analyst, even though those terms may be more familiar in some enterprises. Regardless of organizational structure or title, an effective business owner must exist and they must drive the vision either directly, or through the product management/business analyst organization. An effective Business Owner/Product Manager should exist for each major domain of the solution or the agile teams will be filling in the gaps, possibly with mixed results, depending on their expertise in the various domains. For consistency, we’ll continue to use the term “Product Manager” from here forward, but the reader may wish to translate that into the terms of their enterprise.

Responsibilities of the Product Manager

Agile or not, the Product Manager must fulfill the following responsibilities:

1. Stay abreast of the latest industry trends
2. Understand the changing needs of the market and the customer base
3. Maintain a solid understanding of the current solution

Using this data, the Product Manager’s primary responsibility is to then

1. Articulate a clear direction for addressing gaps and opportunities
   

The Agile Product Manager

Like most every other role in the software enterprise, the Product Manager’s role evolves as the company transitions to agile development methods. The first decision is whether or not the Product Manager assumes the role of the agile Product Owner and thereby takes on the additional responsibilities for iteration planning, story elaboration and prioritization, demo and acceptance. As we’ve noted before, that is probably not practical within the enterprise (see Responsibilities of the Agile Product Owner vs. Enterprise Product Manager and Role of the Product manager ). The differing responsibilities for the two roles are then as highlighted in the following table.

Responsibilities: Agile Product Manager and Agile Product Owner

Agile Product Manager in the Big Picture

As can be seen in the table and as is implied in the Big Picture, we see that the Product Manager owns the Vision and Release (Feature) Backlog and as its implementation in the Release and the
Roadmap. The Product Owner is a charter member of the Agile Team, and owns the User Stories and Iteration (story) Backlog and the implementation via Iterations. Working together, the Product Manager and Product Owner steer the agile enterprise.

To fulfill these responsibilities, the Agile Product Manager:

Owns the Vision – in collaboration with the business owners and the Product Owners, the Product Manager sets the Vision and the prioritized feature set which further describe how the Vision may be fulfilled in the implementation.

Drives the Release Objectives and Priorities through Release Planning – The Product Manager plays a key role in the Release Planning process as well, whereby they have routine and periodic, face-to-face opportunities to communicate objectives directly to the agile teams.

Updates and Maintains the Roadmap – One result of this process is the Product Roadmap, which serves as the plan of record for coupling the Vision to Implementation Timelines. The Product Manager uses the Roadmap to communicate the Product Managers “big picture” to the stakeholders inside and outside the enterprise.

That’s it for the Agile Product Manager. In the next post in the Big Picture Series, we’ll get back to the execution model and describe the role that the Release Management Team plays in helping assure the successful implementation of all that Vision.

Note: A Special thanks to Mauricio Zamora of CSG systems, who contributed some content and insight for this post.

More on the Big Picture (3)- Product Owner vs. Product Manager

In the post Enterprise Agility–The Big Picture (3): Role of the Product Owner, I discussed the differences between the Product Owner and the Product Manager. In the past, I’ve discussed the fact that, at least in the larger enterprise, these are typically NOT the same individual and this is clear from the Big Picture Itself.

Big Picture 3- Product Owner and Product Manager

The reasons are straightforward. Simply, there are typically not enough Product Managers, nor are they necessarily inclined by training or interest to spend some/much/most of their time working directly with the product teams. The math itself is part of the problem. I’ve seen enterprises with up to 400 practitioners operating with as few as 4-6 Product Managers. It simply isn’t practical to assume that they will be able to support the Agile Manifesto Principle: Business people and developers must work together daily throughout the project. Even if they were so inclined, there simply aren’t enough hours in the day. And if they did spend most of their time with the teams, they become further removed from the customer the enterprise is required to serve. That can’t be good. (For more on this topic, check out the Product Owner/Product Manager category on this blog).

Moreover, the effective Product owner exhibits must exhibit a degree of technical competence in order to deserve and earn the respect of the team. As I noted previously,

“the foundation for effective decision making is driven by the technology of the implementation. In addition, continuous refactoring is integral to agile, and since the product owner owns the backlog, prioritizing refactors vs. value stories is a critical skill that requires a technical foundation.”

This blog post has raised some interesting comments which those interested in the topic may want to peruse at Enterprise Agility–The Big Picture (3): Role of the Product Owner.

One in-depth comment in particular, takes some issue with my recommendation (which I still support) that the Product Owner reports into the same line management as the team. To save you time, I’ve incorporated some of those comments from Malamo below:

“I want to expand a bit on the concept of trust. Agile forces a very interesting and powerful change with the Product Mgt and Development relationship. For years, it’s always been the same story – PM asks for too much and Development delivers too little. It’s been a conflict since the beginning of time and it’s always the other person’s fault. For the context of this post, I am going to declare one big assumption: that the product owner is properly skilled and has all the leadership characteristics listed above. The one I will add is that they should be a natural leader – more than anyone else, I believe the product is the person most responsible for keeping the team focused, motivated and engaged.

A good product owner changes the conflict mentioned above – completely. Their alliance is with the team and as a result, the conflict switches from PM vs. Development to PM vs. PO. The PO is the person responsible for ensuring product management is happy with the results. I have seen numerous situations where the PO has passionately defended the team’s performance. It’s a wonderful thing…

The product owner is also responsible for fostering and maintaining a solid relationship with the PM. If this doesn’t happen, it will create significant issues because ultimately the true stakeholders will start to question the ability for agile to deliver better results. The PO becomes the bridge between PM and Development. The PO understands with specificity what it takes to develop SW.

As a result of this shift in conflict, I personally believe all POs should report under the Product Management organization and NOT under development. Nothing changes from what Dean posts above – it’s all still critical. The PO should be collocated. The PO’s alliance is with the team. However, the dotted line (or direct line) relationship to the PM creates a needed balance of power.”

Role of the Product Manager

I’ve been blogging off and on the “agile product manager vs. agile product owner” roles over the last few months. (These are categorized under Product owner/Product Manager) In one post (Responsibilities of the Agile Product Owner vs. Enterprise Product Manager) we noted that within the enterprise, it’s not always appropriate nor feasible to have product managers fill the role of the agile product owner, and we noted that organizing the roles around the release and iteration boundaries/ownership often make sense. See below.

When this happens, while the activities of the product manager role evolve in an agile enterprise, so long as the product owner assumes the basic iteration responsibilities, many aspects of the enterprise product managers role are largely unchanged.

I just came across an article I wrote in 2002 which was my articulation at the time of the growing influence of product managers and their responsibilities within the software enterprise. I’ve posted the article below and on the resource page as well. I think it is still largely relevant to the discussion at hand.

The Role of the Product Manager in a Software Products Company

Ideal Training for Enterprise-Scale Agility?

Pete Behrens (www.trailridgeconsulting.com) and I were formulating a training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach. Based on my experiences at BMC Software and his experiences at Salesforce.com, as well as some of our larger, ongoing clients, we had a chance to reflect on what we would recommend as the “right” amount of training to ensure success. We concluded that for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal. The summary of our training recommendations by role is seen in the figure below:

With this model, all team practitioners receive a minimum of two days of agile training, (agile team training for the each team in the enterprise) which we recommend as the minimum requirement, with an additional day or so of training for specialized roles of Product Owner, Project/Release Manager, and Agile/Scrum Master. All other executives and managers are invited to attend an overview course on scaling software agility.

Each of these courses is described in summary form below.

Agile for Teams –Essential, team-based training in a two day workshop setting that introduces the philosophy, principles, and benefits of agility, agile methods, iterative and release framework, roles, agile technical practices, and agile management practices (Scrum). This is an interactive workshop with a specific project context producing a draft release plan and first iteration (sprint) plan. Training should also include those enterprise extensions applicable to the company’s context.

Agile Release and Project Management at Enterprise Scale – For Project Managers, Release Managers, Program and Portfolio Managers who have responsibility for helping deliver the product(s) to the marketplace. Topics include differences between traditional and agile product management, iteration framework, multi-level release planning and tracking, the agile release train, planning and executing the release planning event, and measuring enterprise progress.

Agile Product Owner in the Enterprise – For team-based product owners/candidates who will become responsible for backlog management, story writing, and iteration and release planning, and who will also be involved in the planning and coordination of larger scale software systems of systems built by teams of teams.

The Agile Master In The Enterprise – For potential agile team leads/future Scrum Masters who will be coaching agile teams and who will interact with other teams as well. Topics include: process facilitation, enterprise agility, mastering the iteration, team roles, release planning and tracking, agile leadership, empowerment and conflict management, and integration Scrums.

Agile Product Manager in the Enterprise – For enterprise product managers with product, product line, portfolio and business unit responsibilities. Topics include: what’s so different about agile, backlog and prioritization, relationship to product owners, PM’s role in release planning and management, visioning and the product roadmap.

Scaling Software Agility – Best Practices for Large Enterprises – For executives and key stakeholders in support, distribution, quality, internal IT, HR and all others whose roles will be impacted by the substantive changes that enterprise agile engenders.

• Part I – overview of agility highlighting lessons learned from the most common and effective agile methods
• Part II – seven team best practices of agility that natively scale to the enterprise level
• Part III – seven organizational capabilities that companies can master to achieve the full benefits of enterprise scale agility

I’m curious to hear whether others think this is too much or too little and what other patterns trainers have found to be effective?