Solution

Click. Boom. Amazing!

—Steve Jobs

Solution Abstract

All the words, pages, links, roles, activities, and artifacts in SAFe live for only one purpose: to help teams continuously deliver Solutions that provide value to the Customer. That, in turn, enables them to achieve their goals, which is the ultimate purpose of the endeavor.

However, even when teams and trains apply SAFe guidance and operate effectively within their areas of concern, value is not ensured. Customers do not buy Capabilities, Features, or components. Rather, they buy solutions that provide desirable business outcomes. For that reason, a solution is one of the central concepts in SAFe, and one that requires taking a systems view on value delivery.

Details

Developing an effective Solution—one that is fit for its intended purpose—is the larger purpose of SAFe. As described in the Value Streams article, a solution is either a final product delivered to the ultimate economic buyer or, alternately, a set of systems that enables an operational value stream within the organization. In either case the work is largely the same: to determine the end user’s needs and to reliably, efficiently, and continuously produce a flow of value to that end user. That is the process of solution development and the subject of all the roles, activities, and artifacts in SAFe.

Overview of Solution Development in SAFe

Solution development is the entire subject of the Value Stream Level in SAFe, and that is the primary perspective of this article. Solution development involves a number of core practices and objects of SAFe, as Figure 1 illustrates.

Figure 1. Overview of solution development
Figure 1. Overview of solution development

Every solution is delivered by a value stream, which is realized by the people on one or more Agile Release Trains. ARTs operate synchronously and build the solution in increments, which are fully integrated and evaluable via the Solution Demo, which occurs at every Program Increment at least. Solution Intent captures the goal of the solution and allows for exploring and defining fixed and variable requirements and designs, which are in part derived from the Solution Context. The Customer interacts with the solution builder to clarify the intent, validate assumptions, and review progress. Solution Management and Architects help drive development, make scope and priority decisions, and manage the flow of Features and Capabilities and Nonfunctional Requirements.

Governance is provided in part by the Economic Framework, which encompasses relevant economic decision rules that govern the logic around the solution. Value Stream budgeting and Strategic Themes provide additional boundaries and inputs.

Developing an economically viable solution requires a holistic approach to definition, planning, implementation, and review of the solution, as is further described below.

Effective Solution Development Requires Systems Thinking

Principle #2 – Apply Systems Thinking guides the organization to adopt a systems view and to apply scalable and emergent practices around value definition, architecture, development practices, and process improvement. Many elements of the framework facilitate this, as described in the sections below.

Solution Capabilities, Enablers, and NFRs

Capabilities are the end-to-end solution services that support the achievement of user goals. Capabilities are implemented via vertical, end-to-end slices of value, which enable incremental solution development. Enablers provide for exploration of new capabilities, contribute to solution infrastructure and architecture, and enhance NFRs. This drives early value delivery and architectural robustness.

Solution Intent

Solution intent drives and captures a holistic view of the solution and includes different aspects that govern value definition, including structural, behavioral, functional, and other views. Model-Based Systems Engineering provides an effective way of reasoning about the solution and also serves as an efficient communication tool for sharing this knowledge. SAFe’s fixed-variable solution intent paradigm enables value streams to enhance solution intent based on the objective knowledge that emerges over the course of many learning cycles.

Customer and Solution Context

Taking a systems view helps ensure that the solution builder understands the solution context, the broader ecosystem in which the solution operates. Solution context provides the additional pieces that determine operational requirements and constraints.

And of course, Customers are part of the value stream. They participate in defining solution intent and solution context, and they help validate assumptions and fitness for use.

Solution Integration, Testing, and Demo

Solution development is effective only when stakeholders and teams frequently evaluate integrated increments of the entire solution. While Solution Demonstration occurs on a fixed PI cadence, Continuous Integration and testing happen more frequently—whenever applicable, in fact. In order to progress on this objective, solution builders continuously enhance their integration and testing practices, configuration management, automation, and virtualization.

Building an Economically Viable Solution

Building a complex solution requires informed, effective decision-making. The trade-offs of the Economic Framework help guide solution development. In addition, a continuous exploration process that includes learning Milestones, Customer feedback loops, and Set-Based Design informs and streamlines the learning process by validating good options and eliminating less viable ones.

Managing Multiple Solutions in the Portfolio

Each SAFe Portfolio contains multiple value streams. Many are largely independent, while others may have a number of cross-cutting concerns and dependencies, as is illustrated in Figure 2.

Figure 2. An example of cross-cutting solution concerns in a portfolio
Figure 2. An example of cross-cutting solution concerns in a portfolio

Sometimes these cross-cutting concerns provide enhanced capabilities that provide strategy differentiation. At other times, they are just dependencies that must be addressed as part of the solution offering. When this is the case, Coordination across value streams is required.


Last update: 31 March 2016