People at work are thirsting for context, yearning to know that what they do contributes to a larger whole.
—Daniel Pink
The Vision is a description of the future state of the Solution under development. It reflects Customer and stakeholder needs, as well as the Feature and Capabilities proposed to meet those needs.
The vision is both aspirational and achievable, providing the broader context—an overview and purpose—of the solution under development. It describes the markets, customer segments, and user needs. It sets the boundaries and context for new features, Nonfunctional Requirements (NFRs), and other work.
The vision applies to any level of SAFe, which explains why it’s on the spanning palette. While its focus is typically on the solution, a portfolio vision is also clearly relevant, reflecting how the Value Streams will cooperate to achieve the Enterprise objectives. Agile Release Trains (ARTs) and Agile Teams may also have their own visions to communicate their part in developing the solution.
Few question the benefit of Lean-Agile’s focus on near-term deliverables and fast value delivery, which favors deferring decisions until the last responsible moment and limiting Work in Process (WIP). This approach also avoids Big Design Up-Front (BDUF), future-proofing architectures, and overly detailed plans. There is no substitute for a bias for action: ‘Let’s build it, and then we’ll know.’
However, in the context of large solutions, every individual contributor makes many decisions. Therefore, continuously developing, maintaining, and communicating the vision is critical to creating a shared understanding of the program’s goals and objectives, especially as those ideas evolve due to ever-shifting market needs and business drivers.
The portfolio vision sets a longer-term context for near-term decisions in a way that is both practical and inspirational: ‘This is something worth doing.’ Understanding the longer-term view helps the Agile teams make more informed choices about the development of functionality in both the short term and the long run.
Lean-Agile Leaders have the most responsibility for setting the strategic direction of the company and establishing the mission for the teams that will implement that strategy. The authors of Switch call this view a ‘Destination Postcard’ (Figure 1) [1].
A portfolio vision exhibits the following characteristics:
Aspirational, yet realistic and achievable – It must be compelling and somewhat futuristic, yet practical enough to be feasible over some meaningful time frame.
Motivational to engage others on the journey – The vision must align with the Strategic Themes, as well as with the individual team’s purpose.
Business Owners (or C-level executives) typically present this longer-term view and business context during the Program Increment (PI) Planning event. These leaders can inspire and align the teams, increasing their engagement and fostering their creativity to achieve the best results.
Product and Solution Management have the responsibility for translating the portfolio vision into a solution vision, indicating the reason and direction behind the chosen solution. Doing so requires specific questions to be asked and answered:
What will this new solution do?
Which problems will it solve?
Which features and benefits will it provide?
For whom will it provide them?
Which Nonfunctional Requirements will it satisfy?
Product and Solution Management work directly with Business Owners and other stakeholders to synthesize all the inputs and integrate them into a holistic and cohesive vision, as illustrated in Figure 2. These inputs include the following resources:
Customers – End users and Customers provide fast feedback and have intimate knowledge of what is needed.
Strategic themes – The strategic themes provide direction and serve as decision-making filters.
Solution Context – The solution context indicates how the solution interacts with the customer’s context.
Solution Backlog – The solution backlog contributes direction and guidance to the vision.
Solution Intent – The solution intent contains some of the vision and is the destination for new elements.
Architect/Engineers – The system and solution architects/engineers support the continuous evolution of the Architectural Runway, which in turn supports current and near-term features.
Agile Teams – The foremost experts in the domain are typically the Agile teams themselves.
Product Owners – The Product Owners continuously communicate and integrate emerging requirements and opportunities back into the program vision.
Given the SAFe practice of cadence-based, face-to-face PI planning, vision documentation (various forms of which can be found in [2], [3], and [4]) is augmented—and sometimes replaced—by rolling-wave vision briefings. These briefings provide routine, periodic presentations of the short- and longer-term vision to the teams. During PI planning, Large Solution level stakeholders, such as Solution Management, describe the current overall solution vision, while Product Management provides the specific ART context and vision.
The relevant elements of the vision, along with details of the current and specific behaviors of the system, are captured in solution intent.
When using Full SAFe or Large Solution SAFe, each ART will likely have its own vision, detailing the direction of the specific capabilities or subsystems that it produces. This vision should be tightly coupled to the solution vision it supports.
Having a sense of direction is critical to planning and engagement. Of course, unless there is some realistic plan for how teams will fulfill the vision, people won’t actually know what they must do. That purpose is filled by the Roadmap. Figure 3 provides an example.
The roadmap is indeed helpful—but for action and execution, the immediate steps must be clear. Product and Solution Management have the responsibility to provide the direction for these next steps. In the SAFe context, this translates into a series of incremental steps forward, one PI at a time and one feature at a time, as illustrated in Figure 4.
To achieve this, Product Management constantly updates feature priorities using the Weighted Shortest Job First (WSJF) model. Then, during PI planning, they present the top 10 features to the team. The team won’t be surprised by the new list, as they will have seen the vision evolve over time and will be aware of the new features that are headed their way. Further, the Program Kanban is used to explore the scope of features, their benefit hypotheses, and their acceptance criteria; thus, when features reach this boundary, they are fairly well formed and vetted. Architect/Engineering has already reviewed them, and various Enablers have already been implemented.
However, everyone understands that the top 10 list is an input to the planning process, rather than an output of, and recognizes that what can be achieved in the next PI is subject to capacity limitations, dependencies, knowledge that emerges during planning, and more. Only the teams can plan and commit to a course of action, one that is summarized in the PI Objectives.
But these features are ready for implementation. And feature by feature, the program marches forward toward the accomplishment of the vision.
Likewise, Solution Management presents a similar top 10 capabilities list during Pre-PI Planning to align the ARTs within a Solution Train.
LEARN MORE
[1] Heath, Chip, and Dan Heath. Switch: How to Change Things When Change Is Hard. Broadway Books, 2010.
[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[3] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
[4] Leffingwell, Dean, and Don Widrig. Managing Software Requirements. Addison-Wesley, 2001.
