The business schools reward complex behavior more than simple behavior, but simple behavior is more effective.

– Warren Buffett

Program Portfolio Management Abstract

Program Portfolio Management (PPM) represents the highest-level fiduciary (economic) and content authority (what gets built) in the Framework. These responsibilities typically rest with those business unit/marketing/development executives who have the

• the necessary market knowledge,
•  technology awareness, and
• best understanding of the internal financial constraints and external market conditions,

and who use that knowledge to drive product and solution strategy. Often, they are assisted by a Project/Program Management Office (PMO), which shares responsibility for program execution and governance.

We consider the domain of concern for this function to be the set of all Programs, both Agile and other, that are included on the Big Picture below the Portfolio level. Within that domain, we consider that this function has responsibility for three critical things:

• Strategy and Investment Funding
• Program Management
• Governance

Lean and Agile approaches to these important functions are described in the details below.

Details

Summary Role Description

The Program Portfolio Management function is typically comprised of line of business owners and/or their representatives, business analysts, enterprise architects, and strategic planners. In accordance with current Investment Themes, they define and prioritize the Portfolio Backlog, which contains the business and architectural epics that drive one or more Agile Release Trains to their respective marketplace solutions.

Responsibility Summary

The three primary responsibilities of the Program Portfolio Management function are as follows:

• Strategy and Investment Funding. Define, develop, or drive high-level strategy for product lines and deployed systems. Allocate investment funding to programs and new initiatives as prescribed by the business fiduciaries.
• Program Management. Drive, participate in, or support successful program execution.
• Governance. Provide closed-loop reporting and feedback on programs in process. Drive, participate in, or support software development lifecycle guidance and effective use of appropriate feedback measures.

Program Portfolio Management Team

Enterprises may use different titles and roles to fulfill these functions, or indeed there may be no official labels or departments, so SAFe calls the collection of people who share the responsibility the Program Portfolio Management Team. While the Program Portfolio Management Team has these responsibilities, they typically do not have the dedicated time or resources necessary to develop the business cases necessary to warrant investment, nor to guide or track the implementation. Therefore, they are typically assisted by two groups

• business analysts, who can elaborate initiatives and determine the impact on the enterprise’s internal and external value streams, and
• System Architects —who can define a technological vision and implementation scenarios that support the business objectives.

In addition, a Program/Project Management Office (PMO) may provide Program Managers who have  skills to shepherd a large program from development to deployment, including governance and reporting. In some cases, this function may even include the responsibility for defining the enterprise’s Software Development Lifecycle (SDLC).

On Legacy Mindsets

Agile or not, it is self-evident that the three primary responsibilities above are necessary for successful business execution. We also note that the historic adoption of the waterfall model, coupled with our general inclination to institute top-down controls over our non-deterministic software research and development process, has caused the industry to adopt certain behaviors and mindsets that are suboptimum and may inhibit the adoption of more lean and Agile paradigms. (This is often painfully evident in the traditional PMO). These legacy mindsets are discussed at length in Ref [1]. While we will address them all in our Agile PPM approach, it is sufficient here to pause only briefly and note just a few:

• widget engineering & order taker mentality. Includes mindsets like “it’s already been defined with our customers, just build it….and… do so on the schedule you’ve been given…”
• control through milestones. Using indirect milestones such as “requirements signoff” to control projects
• we can plan a full year of projects, up-front. The false belief that our market is so stable, our development process is so controllable and deterministic, and our planning is so mature, that we can plan all of our projects for the entire year.

Addressing Legacy Mindsets with Transformational patterns

While this list is not exhaustive, it is a sufficient springboard to allow us to move forward with a more prescriptive set of transformational patterns that can move us into the truly Lean|Agile enterprise. These patterns and their relationships to the primary responsibilities are illustrated in Figure 1 below.

Figure 1. Program Portfolio Management responsibilities and SAFe transformational patterns

Each of these transformational patterns is described later in this document.

Domain of Concern

Before that, however, there is one last important piece of context: the “domain of concern” for our PPM. In the context of SAFe, most programs will be continuously flowing value streams, which we call Agile Release Trains. Others may be legacy programs that follow prior, waterfall or iterative and incremental practices, or perhaps one-time initiatives that have not adopted the Agile paradigm. No matter the method, the PPM responsibilities are the same, as is illustrated in Figure 2.

Figure 2. Program Portfolio Management domain of concern

Program Portfolio Transformational Patterns

Figure 2 highlights a number of transformational patterns—ways in which applying SAFe can address many of the legacy mindsets of our prior development models as described in the sections below.

Strategy and Investment Funding

• Budgets and Investment Themes. Budgets are typically established annually (or twice annually) to define the resource spend for each Release Train. Thereafter, instead of requiring a project charter for each new initiative (and suffering the overhead and project binding that implies), we suggest that initiatives be managed via Investment Themes, each if which implies a capacity allocation to a specific initiative. Within each theme, the content authority (see below) can make fast decisions as needed, so long as the overall budgets are adhered too.
• Visibility, WIP Limits and Flow with the Portfolio Kanban System. Bringing visibility to this important work, and managing Work In Process (WIP) to insure efficient product development flow, is readily managed in the SAFe Architecture and Portfolio Kanban Systems
• Epics and Lightweight Business Cases. In order to provide visibility and economic justification for specific new initiatives within the investment theme, we capture such work as individual Business or Architectural Epics, each of which is warranted by a lightweight business case.
• Decentralized, Rolling Wave Planning. Centralized (often formerly PMO-based) planning for the teams, is replaced with decentralized, team and program-based rolling-wave planning by the teams, via a cadence-based Release Planning activity.

Program Management

• Self-Managing, Self-Organizing Agile Release Trains (ARTs). Traditional project and program chartering and management activities are replaced almost entirely by Agile Release Trains, each of which provides a continuous flow of value to its stakeholders.
• Epic Owner. While the trains themselves are largely self-managing, many epic initiatives are cross cutting, and it is important to have a systematic way of moving these initiatives into each ART Program Backlog. This is managed via the role of the Epic Owner.
• Release Train Engineer. Self-managing doesn’t mean “leadership free”, and Agile release trains are most effective under the auspices of an “uber scrum master”, typically a program manager, who adopts the role of the Release Train Engineer.
• 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, consistently through the Team (story), Program (Feature) and Portfolio (Epic) levels, as is illustrated in Figure 3.

Figure 3.Agile estimating in story points is used at all levels in the system

Governance

• Content Authority. Building decentralized and empowered programs is an assumed part of SAFE. However decentralization vs. content autonomy (ie, controlling what the teams and programs are building), is another thing entirely. Here, we need a clearly defined and understood hierarchy of decision-making, which we call content authority, as is illustrated in Figure 4.

Figure 4. Clear line of content authority in SAFe

• Fact Based Assessment: Metrics and Reporting. Moving from indirect, proxy-based waterfall milestones to fact-based assessment is easy with SAFe. As the program continuously evolves, always working code, and full process visibility are inherently Measurable.
• Agile SDLC Milestones. Gone are the proxy-based milestones and governance model of our waterfall past. In their place we recommend the adoption of Agile milestones, as illustrated in Figure 5.

Figure 5. Agile program milestones are frequently releasable solutions

• Continuous Improvement. The annual (and depressing) waterfall project “post mortems” are replaced by Kaizen mind (translation: always better). Not only is this integral to every person’s every day thinking, it manifests periodically at every team’s Iteration Retrospective, and on the larger and even more critical scale, at each release train’s PSI Inspect and Adapt workshops.

Summary

Learn More

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

Last update 15 January, 2013

© 2010-2013 Leffingwell, LLC and Pearson Education, Inc. All rights reserved.