Management is efficiency in climbing the ladder of success; leadership determines whether the ladder is leaning against the right wall.
Program Portfolio Management Abstract
Program Portfolio Management (PPM) has the highest fiduciary decision-making responsibility 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.
In fulfilling these responsibilities in SAFe, they establish and communicate the Strategic Themes that guide the company’s investments and strategy, and they are stewards of the Portfolio Vision, where they help determine the relevant Value Streams, allocate the Budgets to Agile Release Trains, define and prioritize cross cutting Portfolio Backlog Epics, 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.
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 (Business Epics) 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 (via Architectural Epics) 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  and .
In order to move past these mindsets, we think in terms of 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.
These transformational patterns help us better understand how to fulfill our primary responsibilities, strategy, investment funding, program management, and governance, but in a more effective Lean-Agile fashion as described 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. Value Streams are identified, fostered, proctored and continuously improved. Investment funding is allocated to ongoing programs and new initiatives in accordance with business strategy and current Strategic Themes. Additional Lean-Practices help the enterprise meet its economic objectives:
- Lean-Agile Budgeting. As described in Budgets, 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. Due to their scope, however, Program Epics still require some level of PPM approval.
- Demand management and continuous value flow. Overloading any system decreases throughput. 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 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:
- 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.
- 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 breakdown structures are replaced with Agile estimating and planning, using the currency of Story points, applied consistently through the Team, Program and Portfolio.
Governance functions still exist in agile, otherwise there would be no portfolio-level feedback on investment spend, nor program reporting, nor any means to assuredly communicate and validate important security, regulatory, standards, quality, and release requirements. Governance can be looked at in terms of Measures and Lifecycle Milestones, as we discuss below.
SAFe provides guidance to various metrics that can be used to assess status across the portfolio, these include portfolio-level measures, as described in Portfolio Metrics. and program-level metrics as described in ART Metrics.
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 place of traditional milestones, we recommend the adoption of Agile milestones, Program Increments and Releases, as illustrated in Figure 4.
After charter approval of the release train, the most meaningful internal milestones are Releases and cadence based PIs, with continuous improvement facilitated by quantitative metrics, customer feedback, and the Inspect and Adapt retrospective cycle.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley, 2011.
 Thomas and Baker, DTE Energy. Establishing an Agile Portfolio to Align IT Investments with Business Needs. 2008.
Last update 22 September, 2014
Leffingwell et al. © 2011-2014 Scaled Agile, Inc.
Information on this page 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 permissions@ScaledAgile.com.