Click. Boom. Amazing!
All the words, pages, roles, activities, and artifacts in SAFe exist for only one purpose: to help development teams continuously deliver solutions that provide value to their customer. That, in turn, enables customers to achieve their goals, which is the ultimate purpose of every solution development enterprise.
However, even when teams and trains apply SAFe guidance, and operate effectively within their disciplines, the value isn’t guaranteed. After all, customers do not buy Capabilities or Features. Rather, they buy whole product solutions that deliver desired business outcomes. For that reason, a solution is one of the central concepts in SAFe and requires taking a systems view regarding value delivery.
Developing an effective solution—one that is fit for its intended purpose—is the larger aim of SAFe. As described in the Value Streams article, a solution is either a final product or a set of systems that enable 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 that meets those needs.
Overview of Solution Development in SAFe
Solution development is the subject of each Agile Release Train (ART) and value stream. In the Essential SAFe and Portfolio SAFe configurations, each ART has the ability to deliver a largely independent solution to the customer.
The Large Solution level supports solutions that require multiple ARTs, and typically Suppliers, to build them. At this level, solution development involves several core practices and elements of SAFe, as Figure 1 illustrates.
Large solutions are delivered by multiple ARTs operating together as a Solution Train. ARTs function simultaneously to build the solution in fully integrated increments, measurable via a Solution Demo that occurs at least during every Program Increment (PI). Solution Intent captures evolving hypotheses on what to build and how to build it. But it also facilitates exploring and defining fixed and variable requirements and designs that are derived, in part, from the Solution Context.
The Customer interacts with the development teams to clarify 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 (NFRs).
Governance is provided, in part, by the Economic Framework, which establishes the decision rules that govern the financial objectives of the solution and guides the economic decision-making process. Lean Budgets, Guardrails, the Portfolio Canvas, and Strategic Themes all provide additional boundaries and input. In other words, developing an economically viable solution requires a systems approach to defining, planning, implementing, and reviewing the solution, as further described next.
Effective Solution Development Requires Systems Thinking
Principle #2 – Apply systems thinking guides the organization to institute scalable and forward-looking 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, Features, Enablers, and NFRs
Capabilities and features are the end-to-end solution services that help achieve user goals. Implemented via vertical, end-to-end slices of value, they enable incremental solution development. The distinction between capabilities and features is simply that features can be realized by a single ART, while capabilities are realized by multiple ARTs within a Solution Train. Both capabilities and features must be completed within a single PI. Enablers allow exploration of new capabilities, contribute to solution infrastructure and architecture, and enhance NFRs. This triggers early value delivery and helps build robust architecture.
Solution intent initiates and captures a full view of the solution. It also incorporates different aspects that govern value definition, including structural, behavioral, functional, and other views. Model-Based Systems Engineering (MBSE) provides an effective way of reasoning about the solution and is an efficient tool to share knowledge. Fixed and variable solution intent enables ARTs and Solution Trains 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 requires understanding the solution context—that is, the broader ecosystem in which the solution operates. It 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.
Building an Economically Viable Solution
Building a complex solution requires informed and 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 practical ones.
Integrating, Testing, Demonstrating and Releasing
Solution development is effective only when stakeholders and teams frequently evaluate integrated increments of the entire solution. While the Solution Demo occurs on a fixed PI cadence, all of the activities in the Continuous Delivery Pipeline work to support the continuous creation of value and Release on Demand. To accomplish this objective, development teams continuously enhance their DevOps capabilities as well as integration and testing practices, configuration management, automation, and virtualization.
Managing Multiple Solutions in the Portfolio
Each SAFe Portfolio contains multiple value streams. Many are largely independent, while others may have many cross-cutting concerns and dependencies, as is illustrated in Figure 2.
Sometimes these crosscutting concerns provide enhanced capabilities that allow strategy differentiation. 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: 26 September 2018