Fp Martinelli Graykowski

PM World Today – June 2010 (Vol XII, Issue VI)

PM WORLD TODAY – FEATURED PAPER – JUNE 2010

Agile Program Management: Separating Practice from Myth

By Russ Martinelli & Steve Graykowski

The business climate in which many companies operate today is changing so rapidly that within
a short period of time, both business goals and the project execution plans that support those
goals can change dramatically. In some businesses, if six months pass without a significant
change to plans, there is a high probability that something was missed during planning.
Therefore, there is a high probability that something will be missed in project execution and the
project outcomes.

This scenario is a fact of life in any business where software development is a key component of
product or service development. The challenge that this environment creates is the need to be
able to respond quickly to the changing climate and customer needs, while at the same time
being able to maintain a level of structure to keep work output aligned to the company’s business
goals. This is where Intel and salesforce.com have found value in implementing an Agile
Program Management approach to their software development endeavors.

Unfortunately, there exists a serious misunderstanding of Agile Program Management and how it
is implemented and practiced within organizations. It is quite common for Agile Program
Management to be confused with agile project management as well as with traditional portfolio
management practices. This paper will help to clarify some of these misunderstanding by
describing and demonstrating how Agile Program Management is practiced. Specifically, we
demonstrate how program management practices enable an agile-centered software development
organization to consistently deliver higher-complexity solutions while keeping the solution
outcomes aligned with the top business goals of the firm. Additionally, we demonstrate how
agile methodologies enable a program management-centered organization to be more responsive
in providing solutions and value to its customers.

Demystifying Agile Program Management

Both agile software development and program management practices have proven to deliver
business results. Agile software development adds value to the business by quickly and
continuously delivering product features to one’s customers. Program management provides
continued focus on business results and the coordination of multiple project outcomes toward the
achievement of those business results. By combining the two practices, one gains a powerful
solution delivery system that helps keep product or service development teams focused on
business goal achievement, yet remain flexible to customer and market changes. This is
especially true as solution complexity increases.

© Copyright 2010 by the Program Management Academy and Steve Graykowski
PM World Today is a free monthly eJournal - Subscriptions available at http://www.pmworldtoday.net Page 1


As products and solutions grow in scope to meet the ever-increasing needs and demands of users,
the size and complexity of the development efforts required to produce the products and
solutions grow proportionately. There comes a point for every organization when managing
development efforts as a single project (agile or non-agile) is no longer feasible. When this point
is reached, development of a product or solution has to be disaggregated into multiple projects
and managed as a program.

However, traditional program models rely heavily on up front planning, consume a lot of effort
managing variation to the plan, and are slow to respond to customer and user changes. Agile
Program Management on the other hand provides a flexible program-level framework that is
responsive to customer’s changing needs. It anticipates and encourages change by relying on
built in feedback loops that enable teams and customers to collaborate.

Agile development organizations rely heavily on customer involvement and bottom up planning
and execution. As product and solution complexity increases, the more likely it becomes that
bottom up planning and continuous customer change will create a disconnect between execution
output and the business goals of the enterprise. This is even more likely when business
conditions change while execution teams remain focused solely on delivery of customer
requirements. Agile Program Management uses many of the empirical practices of agile
development while keeping a rigorous eye on the business outcomes.

Agile programs use most of the same constructs that traditional programs use such as focusing
on business goals, managing business risk, and project interdependency maps to name a few. But
the manner in which the program team operates is consistent with agile principles. The
cornerstones of agility - alignment, collaboration, transparency, and cadence - are also applied at
the program level. The difference is that Agile Program Management delivers business value
early and often through the life of the program while maintaining continuous focus on business
goal achievement and integration of multi-project outcomes.

Alignment: Business goals provide the basis for establishing alignment among the project
teams associated with a program. When multiple agile project teams are needed to create the
various elements of a large-scale product, a common mission has to be in place to continuously
align the work and outcomes of each of the teams. The business goals driving the need for a
development effort, along with high level customer requirements, are grouped and driven at the
program level, delegated to the agile project level via the release planning process, and then used
as the measure of success for each of the agile projects and the program as a whole. It is through
this process that alignment is achieved.

Collaboration: On any program, a high level of collaboration is required due to the cross-team
interdependencies that exist. Agile programs are no different. The agile project teams need to
collaborate with each other to validate assumptions, determine and track cross-team
commitments, and fully understand the program business requirements. Collaborative methods
include release planning, sprint reviews and retrospectives. Release planning involves the whole
team in estimating the product backlog, deriving an understanding of the business requirements,



and determining the final priorities. Sprint reviews create an opportunity for stakeholders to
interact directly with the program team to validate and touch what was developed.
Retrospectives are used to improve the development process and are a key tool for agile teams to
increase throughput.

Cadence: The cadence of work and outcome delivery is set at the program level and aligned to
the cadence of the organization as a whole. Each team may have different iteration lengths, but
they need to be synchronized at regular check points so that iteration planning and reviews can
be held at the same time across the whole program. These sync points are also used to set
expectations with stakeholders to keep them informed and actively engaged with the program.
The release cadence creates integration points for all teams to assemble and stabilize program
components, examine feature completeness, address blocking issues, and examine dependencies.

Transparency: There’s a saying in the agile community, “If it smells bad, that's a good time to
act”. Agile teams do not fear bad news because they understand that the sooner an issue or
blocker is realized the cheaper it will be to fix. Transparency also means that the whole program
can see and touch what is in development early and often. This provides stakeholders with
enough information early in the cycle to validate the business case and make any course
corrections when necessary.

Integration: With multiple agile project teams working concurrently to develop and deliver a
product or solution, integration of work output from each of the project teams is a critical
component of Agile Program Management. It is the integration of work output that requires a top
down approach to product or solution definition, as the sum of the parts must equal the whole
product. As the agile project teams pull from the list of business objectives and customer
requirements to establish team level product backlogs and release plans, it is the combination of
all the team level release plans that constitutes the program’s overall release plan. It is the
program management function to ensure that the outcomes contained in the program releases
integrate effectively to create the intended product or solution.

Aligning Agile Outcomes to Business Goals

One of the primary principles of Agile Program Management is that the iterative outcomes from
agile project teams consistently contribute to the achievement of the business goals. Any
product development effort – agile or non-agile – is ultimately about achieving a firm’s business
goals.

The benefits that agile software development methods bring to an organization are well
documented and include the following:

 The ability to realize return on investment quickly;
 The ability to rapidly adjust to changes in the environment;
 The ability to quickly respond to customer needs; and
 Reduction of risk due to exposure of problems early in the development cycle.


In order to realize the benefits above, most organizations implement agile at the development
team or project level. However, many companies (including the companies we work for) have
come to realize that agile software development, especially with the use of Scrum and XP,
results in a product that is developed from the ground up. The whole, or integrated product,
becomes a collection of project outcomes that, when aggregated, may or may not represent the
true intent of the product vision.

Let us look at this problem from an enterprise perspective. The development of a firm’s products
or services represents the means to attain a set of business goals. If project outcomes become
misaligned with the product or service vision during project execution, the result will be a
misalignment between the desired business goal outcome and the actual outcome (Figure 1).

Figure 1: Misalignment between business goals and execution output

There can be many causes for this misalignment, three of the most common that we have
encountered include the following:

 Not all requests for changes from customers are in alignment with a firm’s business
goals. In fact, some changes may be in direct conflict with the business goals.
Implementation of these changes at the project level steer a product away from goal
attainment.



 If agile sprints and releases are time and resource constrained, any de-scoping decisions
needed to keep a sprint or release on schedule may result in elimination of critical
features that deliver the product vision and business value.

To fully succeed from a business perspective, there must be alignment from business goals to
daily agile project outcomes. As Figure 2 shows, alignment begins with a set of business goals
that the firm is trying to achieve over a specified period of time. The product vision must
support attainment of the business goals along with the roadmap of product releases into the
market. From an execution standpoint, agile releases, sprint outcomes and daily outcomes must
all support the product roadmap. When this occurs, alignment is achieved between the firm’s
strategic business goals and its execution outcomes.

Figure 2: Alignment between strategic goals and execution outcomes

One of the primary benefits of implementing program management within an enterprise is that it
serves as the glue that bonds execution outcomes to business strategy. Program management is
strategic in nature and business focused. With Agile Program Management, the program
manager is responsible for championing the business goals driving the need for a particular
product development effort. He or she helps accomplish the attainment of the anticipated
business goals from a leadership position in which multiple agile project teams operate to



produce the outcomes necessary to deliver the business goals. Figure 3 illustrates the Agile
Program Management model graphically.

Figure 3: Aligning Agile Outcomes to Business Goals

Agile Program Management combines top-down business strategy with bottom-up iterative
development and delivery. It begins with the identification of the strategic business goals by the
senior leadership team of the firm. Strategies, in the form of products and services, are then
developed and assigned to program managers to develop and deliver. Delivery is accomplished
through the formation of multiple agile projects, each chartered to develop and deliver its
appropriate portion of the product or service.

The role of the agile project managers (Scrum Masters if using Scrum) is to manage the iterative
creation and delivery of their portion of the product. The role of the agile program manager is to
provide coordination, guidance, and leadership to the agile projects to ensure the iterative
outcomes stay aligned to the business goals throughout the duration of the program.
Additionally, the agile program manager, in partnership with the product owner, is responsible
for insuring customer feedback is continually being received and acted upon.



Scaling Up to Meet Product, Business, and Organizational Complexity

To truly represent the complexity that exists in product development, the attainment of any
single business goal may require multiple product launches, each of which may be comprised of
multiple software releases, and each software release may aggregate the outcomes generated
from multiple cross-organizational agile project teams. This multiplication effect results in
increasing levels of product and organizational complexity as a firm’s products become more
sophisticated, feature-rich, and entrenched in the marketplace.
When this occurs, many companies come to realize that their agile software development
methods alone do not scale adequately to resolve this higher level of product and organizational
complexity. Companies such as Intel and salesforce.com have found that the powerful
combination of agile software development and program management practices provides the
necessary scalability needed to create product development flow. Processes from planning
through development and deployment can be scaled across many teams and ongoing software
releases with agile program management and a synchronized organizational cadence.
There are many ways to scale an agile organization depending on how the enterprise and teams
are organized. A highly matrixed organization versus a strong line management organization,
for example, have starkly different processes and management chains of command that need to
be observed and respected. There is not a single, best approach to scale up an agile organization
so the approaches described here are merely meant as noteworthy practices seen in organizations
such as salesforce.com or Intel. These practices have been proven to work well in these cases
and may be adapted by other organizations.
Let’s start by examining the product development processes in an agile environment. Figure 4
shows an iterative planning cycle starting with Portfolio Management and ending with Release
Management.

Figure 4: The Agile Management Cycle



Product capabilities are prioritized by product management and vetted across product lines.
Product line managers collaborate at this stage and are focused on conceptual product design.
This process serves to create a cohesive unified system with a consistent look and feel. Product
features are also discussed and challenged with regard to business value. The outcome is a
calibrated product backlog that is in complete alignment with the overall business goals.

Program planning starts with a clear picture of the business goals used as input to integrated
release planning. At this stage it is important to note that not all implementation details are
known, but enough information has been gathered about the product so that resources can be
allocated and agile project teams created based on business goals, product features, and major
dependencies.

Each agile team now has a good understanding of the project goals and features and establishes
their team release plans, affirms dependency timeframes and adjusts overall priorities based on
more detailed understanding of the product backlog. At this stage, the project team determines
how many iterations are required to deliver the release plan. Development activities occur
incrementally and continue until the release goals are met. The end of each iteration marks the
point where agile project teams and the overall program team look back and retrospectively
determine what changes need to be made to the plans, processes or even to the product itself
based on what was just developed in terms of a potentially shippable increment. These iteration
reviews represent excellent opportunities for stakeholders, customers and agile program teams to
examine the working product, review planning assumptions, and recalibrate the product backlog
to changing customer needs and business goals.

Each agile team in the program stays aligned through regular roll-up coordination points
facilitated by the program manager. These meetings create opportunities for agile teams to
collaborate at the business goal and architecture level to address issues blocking progress. Cross
functional representation from other parts of the organization that are potentially impacted by the
work in progress also participate at this stage and may include functions such as engineering,
user experience, release management, documentation and quality assurance. In addition there
are program level core team meetings to monitor and manage program risk, review overall
progress, and establish transparency for executive stakeholders. The program core team is
responsible for keeping agile project teams focused on the development goal and helps to
protects them from outside distractions.

Agile Program Management at Intel

Since Intel takes a systematic approach to product development, traditional program
management is well established and practiced. However, due to the need for product feature
flexibility, software development is becoming a more centralized activity where features are
developed and delivered at both the integrated and discrete product level. This need for
flexibility in feature delivery, coupled with the continued requirement that the software needs to
be developed and integrated as part of an overall system prior to delivery to ensure proper



performance for the product end user has created the need to move from the traditional program
management approach to Agile Program Management.

Figure 5 demonstrates the Agile Program Management environment from a product roadmap
perspective. In this example, two product lines are shown, each with a product line manager in
charge of a respective product line, and program managers in charge of the development and
launch of individual products within the product line. The product line manager ensures the
product vision is set and remains aligned to the business goals driving the need for the product
line, while the program managers ensure that the integrated and discrete software products are
developed and delivered in alignment to both the product vision and business goals.

Figure 5: Example Agile Program Management Environment

Within the Agile Program Management structure, the agile software development and release
cycles are an on-going process. In this example, releases occur on six-week increments and each
release is comprised of either two or three sprint outcomes. Sprint duration is determined by
feature content needed for coming releases. The program manager leads the product core team
comprised primarily of the agile project managers, release manager(s), product line manager, and
other functional representatives determined by the various elements of the integrated product
being developed.

The program manager coordinates the work of multiple project teams to ensure that the work is
aligned and aggregates in a product release that delivers the software features required for
product launch. Follow-on market releases provide additional features to Intel’s customers. By
using an agile program management approach, Intel’s customers gain value between product
launches by having access to the latest new features through the market releases.



The role of the program manager has changed as this organization has moved from a traditional
program management development model to Agile Program Management. The most dramatic
change in the role involves a transition from command-and-control leadership to influential and
collaboration-driven leadership.

Agile Program Management at salesforce.com

Agile Program Management at salesforce.com emerged from the need to manage large strategic
initiatives and grew out of established agile software development practices. Salesforce.com is a
cloud-computing company that provides a customer relationship management service and an
application development platform. Since its inception, salesforce.com has been a development
driven organization that started out by relying heavily on the output of a small number of teams
managed by a centralized management chain that directed everything from development to
production. Today the organization manages approximately 60+ scrum teams spanning many
time zones and product lines. However, with salesforce.com’s rapid success that model quickly
floundered as the development group grew to match pace with customer demands causing a drag
in performance on the organization’s throughput. Other challenges the organization had
included lack of predictability, missed dependencies, duplicated features, confusing user
interfaces and functional misalignment with business goals.

Overcoming the hurdles of a more complex and growing organization required significant
changes to the development process. An Agile framework centered on Scrum was selected to
unify development cadence and release cycles into what salesforce.com now calls the Adaptive
Development Methodology (ADM). ADM allows teams to self organize and delivers value
earlier in the development cycle, which now gives management the visibility into progress to
business objectives and make appropriate changes. However Scrum by itself was not enough to
align many teams on a common business objective. Program management was introduced into
ADM to address some of challenges including:

 Specialization of functional expertise
 Increased initiative size and complexity
 Cross-team dependency management
 Alignment on business goals and objectives
 Acquisition integration difficulty

Salesforce.com deploys three major releases a year as depicted in Figure 6. Within each release,
all Scrum teams synchronize on a monthly sprint boundary where it is expected that each team
demonstrate the potentially releasable software increment developed in that iteration.



Figure 6: Salesforce.com Organization Release Rhythm

Program management aligns teams by product line within a product division, for example the
Service and Support product line rolls up into the Applications Division which rolls up with
several other divisions into the whole “service”. The monthly boundaries are critical to the
process and are used as sync points for executive stakeholders and product management to
examine the work in progress and realign priorities based on what is being shown combined with
forecasted market demands. Product backlogs are fluid and change often but never impact what a
team is working on in any given iteration. The release planning process is nimble and only
detailed enough as appropriate for sprint planning.

Program managers lead the integrated release planning process across component teams, keep
track of cross team and cross functional dependencies, and manage program level risks.
Working closely, and in tight partnership with the program manager is the product line manager.
Acting as the voice of the customer, the product line manager is ultimately responsible for the
product capabilities and priorities that each component team is responsible for delivering.

Each Scrum team is responsible for creating a bottoms up iteration plan, selecting onto their
backlog the product capabilities they will deliver and how they will develop them. Each team
estimates the backlog at a high level to get a relative sense of the scope of effort for the whole
release then proceeds to break down the backlog into an iteration plan for development. The
program management function at salesforce.com includes oversight of the release management
process. These are the activities involved in deploying the code base into production
environments. Product lines are rolled up across the organization into a single releasable code
base.

The focus of the Release Program Manager differs from the Product Line Program Manager. The
Release Program Manager is responsible for ensuring all components are integrated across
product lines, performance is stabilized, and that the production environment is not degraded.



Release program managers work closely with technical operations of the company, whereas the
product line program managers focus on business outcomes.

Summary

While once thought to be on opposite ends of the flexibility and structure continuum, agile
software development and program management practices are now being combined to create a
flexible framework to develop and deploy large-scale or complex solutions that are aligned with
and help achieve the business goals of an enterprise. Agile Program Management is an emerging
and powerful capability that provides laser-focus on business goals, rapid delivery of product
features to the market, and agility to respond to business and customer changes.




About the Authors:

Russ Martinelli
Author

Russ Martinelli is a Senior Program Manager at Intel.
He has experience in leading new product
development teams and organizations in both the aerospace and computing
industries. Russ is the co-author of two books “Program Management for
Improved Business Results” (Wiley, 2007) and “Leading Global Project Teams:
The New Leadership Challenge” (Multi-media, 2010). Russ is also the co-
founder and executive director of the Program Management Academy
(www.programmanagement-academy.com). Russ can be contacted at
russ.martinelli@programmanagement-academy.com.

Steve Graykowski

Author

Steve Graykowski is the Director of Applications
Program Management at salesforce.com where he
specializes in cloud computing product development
using agile methods for software development. He is a key contributor to
salesforce.com’s Adaptive Development Methodology (ADM). He has 24 years
of experience in software technology in various roles and sectors including
Stanford Research Institute, Charles Schwab and Systemhouse. He has also
owned and operated a successful IT consulting firm. Steve can be contacted at
steve.graykowski@gmail.com.


Fp Martinelli Graykowski

More Related Content

What's hot

Similar to Fp Martinelli Graykowski

Recently uploaded

Fp Martinelli Graykowski