Agile Product Manager in the Enterprise (6): Responsibility 4- Build an Effective Product Manager/Product Owner Team

Note: this is the sixth (and probably last)  in a series of posts (agile product manager category) on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a continuation of the series on the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Manager/Product Owner series on this blog as well as a series in the Agile Journal. (See the resource page for a mapping to the Agile Journal Article Series).

In an earlier post, Agile Product Manager in the Enterprise (2): A Contemporary Framework, and in earlier works, I described a framework for product management along with a separation of roles for the Agile Product Owner and Agile Product Manager in the enterprise context. I concluded with a suggested set of agile-specific responsibilities that are different than the activities in a pre-agile world. To reiterate: they are:

1. Own the Vision and Release Backlog

2. Manage Release Content

3. Maintain the Product Roadmap

4. Build an Effective Product Manager/Product Owner Team

In prior posts, I’ve described Responsibility 1- Own the Vision and Release Backlog,  Responsibility 2 – Manage Release Content, and Responsibility 3 – Maintain the Product Roadmap. In this post, I’ll describe the specifics of Responsibility 4: Build an Effective Product Manager/Product Owner Team.

————–

Building an Effective Product Manager/Product Owner Team

The Big Picture of Enterprise Agility

In the agile enterprise Big Picture, the “steering wheel” that guides the enterprise to its product outcomes is the relationship between the agile Product Owner and Agile Project Manager.

From a reporting standpoint, I’ve often described the most typical relationship between the individuals in these roles as a “fat dotted line”.

Fat Dotted Line Reporting Structure

Product Managers typically (but not always) report into marketing or business; Product Owners typically (but not always) report into development. However, to make the enterprise steering wheel actually work correctly, Product Owners are also honorary members of the Product Management organization from whence they receive overall product direction. In this role, they may also:

• Attend most relevant PM meetings, functions, and planning sessions.
• Receive input with respect to career growth and performance.

Of course, there is a natural tension in this relationship as the needs of the key constituents (development team vs. customers/market) are quite different.

• The Product Managers naturally want more features-more quickly and from a market perspective, there is no upper limit to their demands.
• Product Owners and development teams naturally want that too, but are sensitized to the inevitable technological, architectural and quality constraints endemic to every large scale software application. They will tend to naturally focus on technology, architecture, and refactoring priorities. From an engineering perspective, there may be no upper limit to their demands!

Needed – A Sense of Balance

This natural tension is a direct delegation of the larger business-versus-technology enterprise balancing act:

• If the business (Product Management) solely has its way, it’s likely that expediency of value delivery will rule and technology/product infrastructure investment will get the short stick. After all, what business owner would not want to accelerate value delivery for current customers at every opportunity? When this happens, the product becomes brittle over time, and eventually it is impossible to implement major new features without major refactoring (or worse).
• If technology (Product Owner/team) solely has its way, there can be little doubt that the product will be built on sound (and the latest!) technology without short cuts or quality compromises. But the business value delivery may get the short stick. After all, what technologist wouldn’t want to build the most extensible and reliable platform to support future customer needs? When this happens, the current pace of value delivery may lag other competitors in the marketplace and marketshare will suffer (or worse).

So the best we can do is first recognize and balance these competing interests and  occasionally let the balance tip a little this way or that (refactoring vs. new value stories) based on the current business and solution context.

Needed: A Sense of Balance

Perhaps more importantly, this friction is both a necessary and productive  facet of the enterprise, for it is in the heat of this natural friction and its constant resource constraints, that the sparks of true innovation and creativity are born.

Write less code-accomplish more!

Ingredients for an Effective Relationship

In earlier posts, Jennifer Fawcett (agileproductowner.com) has commented on how important it is to build an effective relationship amongst these teams. She noted that the essential ingredients for building the ultimate Agile Product Owner/Agile Product Manager team are Collaboration, Partnership and Trust. Together, we provide a few tips for building these essential ingredients:

Collaboration – An addition to the joint, enterprise release planning functions, teams must synchronize and communicate the ever-changing corporate priorities daily. POs should invite PMs to attend daily stand-ups on occasion. Politely insist on attendance at most/all demos. Have an “open door” policy for all development and product management meetings.  If one party cannot attend, summarize results in minutes or email. Communicate constantly.

Partnership – Ask each other “How can I help?” Create and participate in after hour events to eliminate any us – vs. – them thinking.  Prepare for release planning together. Operate under the “never surprise each other in front of others” rule.

Trust – Trust each other to make the right decisions. When (not if!)  your APM/APO partner makes a decision that is opposite of yours,  support that decision. Meet your commitments to each other. Teams will recognize that you are both empowered, that you will always act as a team and “cover each other’s backside” and that you can both be trusted with business decisions and authority.

Summary

This concludes this series in the the Role of the Product Manager in the Agile Enterprise. I’m not sure what I’m going to write about next, but I’ll let you know when I figure it out.

Agile Product Manager in the Enterprise (5): Responsibility 3 – Maintain the Product Roadmap

Note: this is the fifth in a series of posts on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a continuation of the series on the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Manager/Product Owner series on this blog as well as a series in the Agile Journal. (See the resource page for a mapping to the Agile Journal Article Series).

In an earlier post, Agile Product Manager in the Enterprise (2): A Contemporary Framework, I described a framework for product management and a separation of roles for the Agile Product Owner and Agile Product Manager in the enterprise context. I concluded with a suggested set of agile-specific responsibilities that are different than the activities in a pre-agile world. To reiterate: they are:

1. Own the Vision and Release Backlog

2. Manage Release Content

3. Maintain the Product Roadmap

4. Build an Effective Product Manager/Product Owner Team

In prior posts, I’ve described Responsibility 1- Own the Vision and Release Backlog and Responsibility 2 – Manage Release Content.  In this post, I’ll describe the specifics of Responsibility 3: Maintain the Product Roadmap.

————–

As we have described the Vision so far, it has been presented as time-independent. This is appropriate as the objective is to communicate the gestalt of “what this thing is we are about to build” and overloading the Vision with prospective timelines will likely quickly derail the discussion of the “what”.

However, in order to set priorities and plan for implementation, we need an additional perspective, a product Roadmap that provides a view we can use to communicate future objectives to our outside stakeholders. An agile Roadmap is not a particularly complicated thing, nor is the mechanical maintenance of it difficult. For example, a typical Roadmap might be communicated in a single graphic as follows:

Sample Graphic Representing a Product Roadmap

The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set. While it is a simple thing mechanically to represent the Roadmap, figuring out the content for anything beyond the next release is another matter entirely. The topic of what else the team plans to ship and when can be a fascinating and contentious topic in agile. However, the easiest way to think about the Roadmap is that it is an output, rather than an input to the Release Planning process.

• The dates and themes for the next release are fixed. The features are prioritized and variable.
• The teams can commit only to the features in the next upcoming release. Releases beyond the next, represent only a best estimate.

The Roadmap, then, is a “plan of intent” and is subject to change as development facts, business context and customer needs change. With respect to the upcoming release, perhaps the most important guidance is this:

Even though the team has committed to the objectives and we have agreed that the feature set cannot be guaranteed, it is a reasonable expectation that the agile teams will:

1) meet the date

2) accomplish the theme

3) deliver most of the features, and certainly the highest priority ones, with the requisite quality.

Anything less would be unprofessional and belie the power, discipline and accountability of our agile enterprise model. Moreover, it will eventually threaten our own empowerment, as failure to deliver will inevitably cause the implementation of various controls to “help us”!

On Confidence and Commitments for Release Next, Next +1 and More

With the enterprise release planning function, the objectives and prioritized feature set for “Release Next”  should be a high confidence plan of intent, at least for those agile enterprises who have some initial degree of maturity. And to be flippant for a second, it’s often true that release Next +1 has a pretty clear definition as well, if for no other reason than it usually “must” contain all the stuff that didn’t fit in release Next! After that however, most bets are off and the enterprise must rely on its portfolio level agile estimating and planning, assuming that such a degree of maturity exists in the enterprise. (click here for more on Portfolio estimating).

In any case whoever, it is important to keep any such future commitments abstract so that the intent can be met under most normal circumstances. After all, if long term commitments are fixed, then you have essentially re-entered a waterfall model of fixed resources, fixed time and fixed scope. Even worse, in so doing, the enterprise will lose its ability to adapt to change, which was the purpose of agile to begin with!

Summary

This concludes Agile Product Manager Responsibility 3 – Maintain the Roadmap. In the next post, I’ll describe Responsibility 4 – Build and Effective Product Manager/Product Owner Team.

Agile Product Manager in the Enterprise (4): Responsibility 2 – Manage Release Content

Note: this is the forth in a series of posts on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a continuation of the series on the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Manager/Product Owner series on this blog as well as a series in the Agile Journal. (See the resource page for a mapping to the Agile Journal Article Series).

In an earlier post, Agile Product Manger in the Enterprise (2): A contemporary Framework, I described a framework for product management and a separation of roles for the Agile Product Owner and Agile Product Manager in the enterprise context. I concluded with a suggested set of agile-specific responsibilities that are different than the activities in a pre-agile world. To reiterate: they are:

1. Own the Vision and Release Backlog

2. Manage Release Content

3. Maintain the Product Roadmap

4. Build an Effective Product Manager/Product Owner Team

In the last post, I described Responsibility 1- Own the Vision and Release Backlog. In this post, I’ll describe the specifics of Responsibility 2: Manage Release Content.

————–

Managing Release Content

In accordance with the Big Picture model, the Vision for the product is delivered to the market in a stream of continuous and frequent, small releases (typically, every 60-120 days) as figure 1 below shows.

Figure 1 - The Big Picture and it's Agile Release Train

Each release is defined by a fixed date, theme, planned feature set, and fixed quality requirements- scope is the variable. Product Managers deliver the vision to the development teams face-to-face in the periodic Release Planning events.

Release Planning Event

In the Big Picture, all agile teams who build cooperative subsystems operate on a synchronized Agile Release Train model. Periodic release planning is the seminal event that aligns the individual teams to the overall strategy of the enterprise. As such, the Release Planning event is to the enterprise what iteration planning is to the team‒the fixed pacemaker that drives the enterprises delivery cadence. As such, Release Planning is the focus of much preparation, communication, coordination and commitment. Teams whose software must cooperate  plan together, and they do so face-to-face, at least so far as travel budgets will allow. (Note: for more on release Planning, click here).

Since the release dates are fixed in advance on the Agile Release Train, Release Planning events are routine and can be pre-scheduled as far as a year in advance. During release planning, team members attend in person if at all possible. During the event:

• Product Management owns the feature priorities
• Development team/product owner owns story planning and high-level estimates
• Architects work as intermediaries for governance, interfaces and dependencies

Preparation for the Release Planning Event

As the Release Planning event is the primary communication and coordination point for product strategy for the upcoming release period, Product Managers should be come well prepared:

• Understand  the status of the current (in process) release
• Update the release backlog
• Meet with other business owners and other Product Managers to coordinate initiatives and priorities
• Meet with Product Owners and discuss the preliminary Vision for the upcoming release.

The event is typically a full day minimum, more likely two, and often follows a pattern as illustrated in the two figures below.

Figure 2 - Enterprise Release Planning Day 1

Day 1 is focused on delivery of the Vision, which the Product Managers deliver via whatever medium suits them best, followed by initial planning by the teams.

In most cases, the Vision doesn’t “fit” in the release time frame provided, (after all, what self-respecting product manager would bring less vision than the teams could likely accomplish) and some Day 2 scope management triage and out-of-box  thinking is required.

Figure 3 - Enterprise Release Planning Day 2

In any case, Day 2 should bring a commitment to the release objectives for the next release. Even then, the commitment has to be flexible (otherwise you have fixed time-fixed-scope-fixed quality; in other words a short waterfall-constrained release) and many agile teams communicate the feature release priorities on a  flexible basis like this:

Figure 4 - Prioritized Release Features

In this manner, the Product Managers control the release content, as well as the delivery priorities. And since teams become far more reliable on their release commitments as they master  the new agile paradigm,  this gives the product managers and external stakeholders a more certain planning basis on which to make key decisions.

Tracking the Release

All the hard work the enterprise has put into the agile transformation should now start paying dividends. For once a commitment is achieved, the primary responsibility for delivering the release in a series of short iterations lays with the project teams. After all, they write and test all the code, and in agile they are both empowered and accountable to achieve the agreed to objectives.

Even then, however, the agile enterprise recognizes that continuous tradeoffs of changing requirements and scope is inevitable, so the Product Manager also plays a pivotal role in helping the teams meet the release objectives. Doing so requires ongoing tracking and managing of the release and its content. Fortunately, our agile enterprise model is replete with visibility, so understanding the actual vs. planned status of a release is no longer a “crystal ball” activity. Instead, there are four primary mechanisms which help the enterprise and its key product manager stakeholders keep the agile release train on its rails.

#1 – Constant Informal Communication with the Product Owners

The product Manager has a direct liaison to the teams via the team’s Product Owners. The fan-out is not too extreme – a single PM may typically interact with some small number (3-6) of product owners– and thereby have ready status from all the project teams who must collaborate in meeting the release objectives

#2 – Participation in the Release Management Team

In the Scaling Software Agility book and blog, I’ve described a typical construct where development management, agile/ScrumMasters, Product Managers, quality assurance, release managers and other key stakeholders meet weekly to assess the status of a release. This Release Management Team (or RMT) has the primary responsibility for shepherding the release to market. This weekly forum is a key touch point through which Product Managers can assess release status, and adjust scope where necessary.

#3‒Attendance at iteration demos

The inherent visibility of agile development also provides an inherent opportunity to see the working code as it develops. This happens in the context of the iteration (Sprint) review which contains both a product demo and retrospective. The every-other-week product demo is key to the Product Managers insights into status and progress and is a not-to-be missed opportunity to see the product, interact with the teams, provide feedback and make midcourse adjustments where necessary.

#4- Status via agile project management tooling

To have even reached this point, the enterprise will assuredly have rolled out appropriate agile project management tooling which provides support for the higher level status views needed by PMs and other stakeholders. This tooling should provide some form of hierarchical, feature-level burn down so that the PM can assess, on an aggregate basis, exactly where they stand within the release as figure 5 shows:

Figure 5- Release Level Burn Down

This chart provides a sense of the probability of landing the release. However, it doesn’t give any notion of what features may or may not be delivered. For that, the tooling should also provide default reports on the status of each individual feature, perhaps something like figure 6 below.

Figure 6 - Status of Release by Feature

Together, this information should give the RMT and the Product Managers objective knowledge of where they are, and even more importantly, what changes might be necessary to “land” the release on time.

Summary

This concludes the discussion of Agile Product Manager Responsibility 2 – Manage Release Content. In the next post, I’ll describe Responsibility 3 – Maintain the Product Roadmap.

Speaking at Agile 2009

I’ll be giving an updated version of my scaling agility presentation at Agile 2009. I’ll be speaking on the Agile Adoption Stage in the Toronto Room at 2 PM Wednesday, August 26th. You can see the full program schedule here.

The abstract for my presentation is below. Also, we’ll be having a meeting of the Lean Software And Systems Consortium board on August 24th and 25th, so if you have any input for that meeting regarding corporate or academic membership, body of knowledge, certification or whatever, please let me know.

==========

Dean Leffingwell describes how agile methods are being successfully applied to enterprise-class development. • Part I describes team practices that scale to the enterprise, including: structuring agile teams, mastering the iteration, concurrent testing and continuous integration. • Part II describes additional practices necessary to achieve full enterprise benefits. Topics include: intentionally emergent architectures, lean requirements at scale, coordinating releases with the agile release train, agile training and rollout strategies and measuring business performance.