Management is efficiency in climbing the ladder of success; leadership determines whether the ladder is leaning against the right wall.

– Stephen Covey

Program Portfolio Management Abstract

Program Portfolio Management (PPM) represents the highest-level fiduciary (investment and return) and content authority (what gets built) in the framework. There, the responsibilities for Strategy and Investment Funding, Program Management, and Governance rest with those business managers and executives who understand the enterprise business strategy, technology, and financial constraints, and define and implement the portfolio product/solution strategy. They are typically assisted in these duties by a Project or Program Management Office (PMO), which shares responsibility for guiding program execution and governance.

However, as is the case with many other functions in the enterprise, legacy approaches to fulfilling these responsibilities are often not immediately supportive of Lean|Agile development, so change is in the works here, too.


Program Portfolio Management (PPM) represents those individuals who have the primary responsibility for Strategy and Investment Funding, Program Management and Governance, as is illustrated in Figure 1.

Figure 1. Primary responsibilities of program portfolio management

Figure 1. Primary responsibilities of Program Porfolio Management

In fulfilling these responsibilities in SAFe, they are stewards of the Portfolio Vision, determine the relevant Value Streams, control the budgets through Investment Themes, define and prioritize cross cutting Portfolio Backlog Epics, guide and assist Agile Release Trains, and report to the business on investment spend and program progress. During the transition to Lean|Agile, the function may have responsibility to fulfill these responsibilities for both agile and traditional waterfall programs, as Figure 2 illustrates.

Figure 1. Program Portfolio Management responsibilities and SAFe transformational pattern

Figure 2. PPM responsibilities cover both Agile and Waterfall programs where necessary

Program Portfolio Management Team

Enterprises may use different titles and roles to fulfill these functions, or perhaps there are no official labels or departments for some, but the responsibilities are clear. SAFe calls the collective of people who share this responsibility Program Portfolio Management.

While the executives are ultimately responsible for this work, they typically do not have the time or skill sets necessary to develop the business cases, nor personally guide or track all the implementation work. Therefore, by extension, PPM may include:

  • Program/Project Management Office (PMO) — able to shepherd large programs from development to deployment, and provide status and financial reporting. This function may even include the responsibility for defining the enterprise’s Software Development Lifecycle (SDLC).
  • Business analysts—who can elaborate initiatives and determine the impact on the enterprise’s internal and external Value Streams
  • Enterprise and System Architects—who can define a technological vision and implementation scenarios that support the business strategy.

Lean|Agile Program Portfolio Management

Effective fulfillment of these responsibilities is a prerequisite for business success. However, historical use of the waterfall model, coupled with our somewhat natural inclination to institute top-down controls over non-deterministic software development, has caused the industry to adopt certain behaviors and mindsets that can seriously inhibit the adoption of more effective Lean and Agile paradigms. These legacy mindsets, such as “widget engineering”, “maximize utilization”, “just get it done”, are discussed at length in Ref [1] and [2].

In order to move past these mindsets, SAFe provides a set of seven transformational patterns that can be used to move the organization to Lean|Agile Program Portfolio Management, as illustrated in Figure 3.

Figure 3 Transformational Patterns

Figure 3. Seven transformational patterns for Lean|Agile Program Portfolio Management

These patterns help us better understand how to fulfill our primary responsibilities, but in a more agile and more effective fashion, as illustrated in Figure 4.

Figure 4. Lean|Agile transformational patterns help guide the fulfillment of PPM responsibilities

Figure 4. Lean|Agile transformational patterns help guide the fulfillment of PPM responsibilities

Each of these patterns is discussed in the sections below.

Strategy and Investment Funding

The purpose of strategy and investment funding is to facilitate implementation of the business strategy through programs that develop and maintain the company’s value added products and services. Investment funding must be allocated to ongoing programs and new initiatives in accordance with business strategy. This information is captured and managed via the Portfolio Vision, and is assisted by the following patterns:

  • Decentralized budgeting and decision-making. SAFe recommends that each Agile Release Train has its own budget, which is updated twice annually. By allocating the budget authority to the decision makers on the train—albeit under the auspices of the Business Owners—it is no longer necessary to establish a charter for each new initiative (Feature). This avoids overhead and project stop-start discontinuities; the train can make fast and local decisions as needed, within the constraints of the allocated budget.
  • Demand management and continuous value flow. Overloading any system decreases throughput, and that is certainly true of software development. If demand isn’t managed at the portfolio, the invisible killer of “too much WIP” will limit velocity and quality as teams and individuals thrash from initiative to initiative. Bringing visibility to existing program work and understating agile program velocities helps manage WIP and insure efficient product development flow. This is managed and supported by implementation of Architecture and Portfolio Kanban systems, and maintenance and visibility of the Portfolio Backlog.
  • Epics and Lightweight Business Cases. In order to provide visibility and economic justification for upcoming, cross cutting work, Business or Architectural Epics are defined and analyzed, each supported by a lightweight business case. Developed by Epic Owners, lightweight business cases provide for reasoning, analysis and prioritization while avoiding over-specificity.

Program Management

Program Management supports and guides successful program execution. While this responsibility lies primarily within the Agile Release Trains and the Release Train Engineer, the PPM function can help develop, harvest and apply successful program execution patterns across the portfolio. In many organizations, the RTE’s are part of the PMO, where they can share best practices and common program measures and reporting. In other cases, they report into the development organization.

However, in either case, as compared to traditional organizations, agile program management delegates many of the traditional functions to the programs, including:

  • Decentralized, Rolling Wave Planning. Centralized planning is replaced with decentralized, program and team-based rolling-wave planning, via the routine, cadence-based Release Planning activity.
  • Agile Estimating and Planning. The formerly too-detailed business cases, too-early requirements specificity and too-detailed work break down structures are replaced with Agile estimating and planning, using the currency of Story points, applied consistently through the Team, Program and Portfolio.
  • Self-managing Agile Release Trains. Traditional project and program chartering and management activities are replaced by Value Stream based, self-managing and self-organizing Agile Release Trains, each of which provides a continuous flow of value to its stakeholders.


The governance function still exists in agile, otherwise there would be no portfolio-level feedback on investment spend, program reporting, nor any means to assuredly communicate and validate important security, regulatory, standards, quality, and release requirements. However, Agile governance is very different from the traditional approach, and is based on:

  • Objective, code-based measures and milestones. Instead of reporting on indirect, document-based milestones, SAFe depends on the objective evidence provided by the working code, along with other program measures and feedback, which is aggregated and assessed primarily at PSI boundaries. (See Metric M5.)

In addition, if the PMO or PPM is involved in development or support of software development lifecycle guidance, then those guidelines should encourage and support incremental development and fast customer feedback. In their place we recommend the adoption of Agile milestones, as illustrated in Figure 5.


Figure 5. Agile Milestones

Figure 5. Agile program milestones are PSIs and frequently releasable solutions

After charter approval of the release train, the most meaningful internal milestones are the cadence based PSIs, with quantitative metrics, customer feedback, and the Inspect and Adapt continuous program improvement cycle.


Program Portfolio Management represents the authority for oversight of strategy and investment funding, program management, and governance for a specific portfolio of programs in the enterprise. As such, this function has the primary responsibility for driving economic benefit for a portfolio. As compared to traditional approaches, SAFe prescribes a number of transformational patterns which empower teams and programs, decentralizes decision making and speeds time to market, thereby helping deliver the business benefits of an always improving, Lean|Agile software enterprise.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley, 2011.

[2] Thomas and Baker, DTE Energy. Establishing an Agile Portfolio to Align IT Investments with Business Needs. 2008.

Last update 21, September, 2013

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact