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) represents the people who have the highest-level strategy and fiduciary decision-making responsibility in the framework. In larger Enterprises, there will be multiple SAFe Portfolios, each helping to manage a set of initiatives, typically at the business unit or departmental level. Each SAFe portfolio has a PPM function, where 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 have the ultimate responsibility for defining and implementing their portion of the overall enterprise strategy. They are often assisted in these duties by a Project or Program Management Office (PMO), which shares responsibility for guiding program execution and governance.
Enterprises may use different titles and roles to fulfill these functions, or perhaps there are no official names or departments for some; nevertheless, effective fulfillment of the responsibilities is necessary for success.
Program Portfolio Management (PPM) represents those individuals who have the primary responsibility for Strategy and Investment Funding, Program Management, and Governance within a specific SAFe portfolio, as illustrated in Figure 1.
Organizations may use different titles and roles to fulfill these responsibilities or there may not be an official department for PPM. What we call this group or the roles within it is a secondary concern, however, effective fulfillment of the responsibilities is necessary for success.
Responsibilities of Program Portfolio Management
PPM has the responsibility to participate in the establishment and communication of the Strategic Themes that guide the enterprises investments and strategy, determine the relevant Value Streams and allocate Budgets to them, define and prioritize crosscutting Portfolio Backlog Epics, and report to the business on investment spend and progress via Key Performance Indicators (KPIs) and other aspects of portfolio context (for more on portfolio context, see Enterprise).
During the transition to Lean-Agile, the PPM function may need to fulfill these responsibilities for both Agile and traditional waterfall programs, as Figure 2 illustrates.
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 the somewhat natural inclination to institute top-down control over software development, has caused the industry to adopt certain behaviors and mind-sets that can seriously inhibit the adoption of more effective Lean and Agile paradigms. These legacy mind-sets, such as “widget engineering,” “maximize utilization,” and “just get it done,” are discussed at length in  and .
SAFe describes 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 the primary responsibilities—strategy and investment funding, program management, and governance—but in a more effective Lean-Agile fashion. Each is further described below.
Strategy and Investment Funding
The purpose of strategy and investment funding is to support implementation of the business strategy through programs that develop and maintain the company’s value-added products and services. Value streams are identified, fostered, monitored, 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 Value Stream has its own budget, which is typically updated twice annually. By allocating the budget authority to the decision makers—albeit under the continuous review of the Business Owners—it is no longer necessary to establish a “project” for each new initiative. This avoids overhead and enables the train to make fast and local decisions as needed, within the constraints of the allocated budget. Due to their large scope, epics still require some level of PPM approval and oversight.
- Demand Management and Continuous Value Flow. Overloading any system decreases throughput. If demand isn’t managed at the portfolio level, 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 the Portfolio Kanban system and maintenance and visibility of the portfolio backlog.
- Epics and Lightweight Business Cases. In order to provide visibility and economic justification for upcoming, crosscutting work, 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 Value Stream Engineers (VSE) and Release Train Engineer (RTE), the PPM function can help develop, harvest, and apply successful program execution patterns across the portfolio. In many organizations, the VSE and RTEs and 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, 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 PI 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, value stream, 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 providing portfolio context and Life-Cycle Governance.
Portfolio context includes:
Key Performance Indicators. KPIs can include quantitative and financial measures, such as ROI, market share, customer net promoter score, innovation accounting, and more. Many additional, portfolio, value stream and program metrics are described in Metrics.
Qualitative data. Qualitative data can include Strengths, Weaknesses, Opportunities and Threats (SWOT) analysis, and most importantly, the accumulated solution, market and business knowledge of the portfolio stakeholders.
The guidance of SAFe principles (namely, Principle 4 – Build incrementally with fast, integrated learning cycles and Principle 5 – Base milestone on objective evaluation of working systems), along with support from PPM, should encourage and facilitate incremental development and fast customer feedback. In place of traditional milestones, Agile milestones include Program Increments and incremental Releases, as illustrated in Figure 4.
By far the most meaningful internal milestones are the above 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. Addison-Wesley, 2011.
 Thomas, Joseph and Steven Baker, DTE Energy. Establishing an Agile Portfolio to Align IT Investments with Business Needs. 2008.
Last update: 5 January 2015