The future belongs to those who see possibilities before they become obvious.
– John Scully
Portfolio Vision Abstract
At the top of the Big Picture, we find a number of elements, which together, represent the Portfolio Vision for the programs in the Program Portfolio Management domain of concern. The portfolio vision reflects an elaboration and commitment to action to the enterprise’s business strategy. It is expressed initially in Investment Themes, which represent the purposeful investments of time, money and resources to achieve individual strategy objectives. Many of the investment themes translate directly to Agile Release Trains, which are long-lived, continuous-flow programs dedicated to achieving that portion of the vision. Other elements of the portfolio vision are carried through the Portfolio Backlog, which contains cross cutting business and technology Epics necessary to achieve the greater business purpose. Since effective decision-making drives economic results, and decentralizing control helps accelerate value delivery, SAFe provides guidance on the roles, responsibilities and activities necessary to capture and implement the portfolio vision to achieve business results.
The Portfolio Vision represents the highest-level business strategy construct in SAFe. In the context of the Big Picture, this vision represents the business drivers behind each of the value streams, which are the Agile Release Trains (as well as potentially some non-agile programs, see Program Portfolio Management governance section) within the Big Picture domain of concern. Figure 1 illustrates the SAFe elements that capture the vision and translate it into actionable form. Each of these elements is described in the context of the Portfolio Vision in the sections below.
SAFe uses the constructs of Investment Themes—key value propositions that provide marketplace differentiation and competitive advantage—as the primary investment governance element in the program portfolio. Each represents a purposeful, known, and measurable ongoing investment in one or more systems, products and applications that the teams are developing. For example, in the hypothetical email system described in ASR [Ref 1, Chapter 23], the following investment themes were identified.
- Introduce voice and video chat
- Outlook integration
- Mail for Mobile devices
- Group chat from within mail
As you could guess from the examples, investment themes are fairly long lived, and it is common for an investment theme to drive business for years to come.
Value Streams/Agile Release Trains and Operating Budgets
Since investment themes are indeed long lived, they lend themselves extremely well to the continuous flow-based Agile Release Trains of SAFe. In this way, there is no need for the delays and overhead of starting and stopping “projects”, rather the value stream is funded at approved levels as long as necessary. In Figure 1, we’ve modeled each release train as an individual investment theme, thereby establishing a current operating budget, and implied resources and resource constraints, for each train in the portfolio.
Content decisions (the Features that define what the system does) are made by the Product Manager/Product Owner hierarchy, placed in the Program Backlog and prioritized using WSJF. The value stream Vision and Roadmap which drive the program backlog are continuously evolved based on customer feedback, Product Management strategy, and inputs from the Portfolio Backlog (discussed below).
In Figure 1, we’ve modeled one additional, “interstitial” investment theme, which represents the portfolio backlog of Business and Architecture Epics. Driven by broader market feedback, business opportunities, mergers and acquisitions, etc., this backlog is used to prioritize more temporal, cross-cutting initiatives that have made their way through the lightweight business cases, WSJF prioritization mechanisms and decision authority of the Business Epic Kanban and Architectural Epic Kanban systems. With respect to budgeting, each new initiate may be funded individually by allocating additional recourses to the affected release trains. Alternately, trains just assume some capacity allocation for these initiatives, knowing that they may occasionally trump other priorities in their local backlog.
Keeping Things Lean with Decentralized Control
When scaling agile development, we must constantly keep in mind that bigger isn’t always better, especially when it comes to keeping the entire system, and thereby the enterprise, lean. To this end, we constantly reflect and apply the lean philosophy and principles and practices we’ve highlighted. This is particularly relevant at this level of SAFe, because the selection and implementation of strategy are the most critical economic decisions the enterprise can make; nothing will be quick and lean if this part of the process isn’t. To this end, we are reminded of the eighth major theme, Decentralize Control, of Reinertsen’s Principles of Product Development Flow [Ref 2], that we highlighted in the SAFe Lean Big Picture element. Reinertsen’s further decentralization Principles D9, establish clear roles and responsibilities, and D1 and D2 below, provide the additional guidance we need in this context:
- D2: Centralize control for problems that are infrequent, large, or have significant economies of scale. Clearly, an effective business strategy can’t be established by adding up the opinions of tens or hundreds of teams. Some things must be determined top down. In SAFe, we assume the responsibility and authority for evolving program portfolio strategy belongs to the business executives who have the ultimate fiduciary responsibility to the stakeholders. They achieve these objectives, in part, by delegating implementation responsibility to Program Portfolio Management and those business analysts, Enterprise Architects and others responsible for the portfolio kanban systems.
- D1: Decentralize Control for problems and opportunities that age poorly. In order to provide fast, empowered decision making for the problems and opportunities that age poorly, we assign the responsibilities for fast moving content and technology decisions to the local control of the Agile Release Trains, the Agile Teams, product managers, Product Owners and Release Management Team.
In this way, we can exercise our responsibilities as empowered professionals, within established boundaries, making for fast and effective decision-making, and thereby providing a fast, continuous flow of business value to our stakeholders.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
 Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
Last update: 9 May, 2013
© 2010-2013 Leffingwell, LLC. All rights reserved.