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.

The Big Picture and it's Agile Release Train

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

Picture 10In 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 teamthe 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

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

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

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

Picture 14In 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.

#3Attendance 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

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

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.


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.


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

    • Thanks. I’ll probably pull a whitepaper together at the end. In the meantime, just point them to the blog because that’s where my new content usually appears first.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s