Click. Boom. Amazing!

—Steve Jobs

Solution

A Solution is a product, system, or service that provides value to internal or external customers.

All the words, pages, roles, activities, and artifacts in SAFe exist for one purpose and one purpose only: to help Agile teams continuously deliver solutions that provide value to the Customer and the Enterprise. In turn, that enables customers to achieve their goals.

However, value isn’t guaranteed even when teams and trains apply SAFe guidance. After all, customers do not buy Capabilities or Features; they buy whole-product solutions that deliver their desired outcomes. Understanding a solution becomes essential to understanding value delivery in SAFe.

Details

In SAFe, solutions deliver the Portfolio’s value. Therefore, accelerating solution delivery is vital for organizations to survive and thrive in the Digital Age. Instead of focusing on projects and defining success as completing them on time and within budget, enterprise leaders must emphasize solutions that deliver business outcomes. This change requires the new organizational and management structures that SAFe advocates, moving from Projects to Products. [1]

In SAFe, the term ‘solution’ is intentionally general, defined as a product, system, or service that provides value to internal or external customers. A solution can be a small mobile application built by a single Agile Release Train (ART) or a large automotive system of systems built by a network of Development Value Streams (DVSs) in a supply chain. It may also be an insurance or banking product offered by a financial institution. Solutions can be the products a company sells or the internal products they use to run the business. They may provide direct value to an end-user or may be a component of a larger solution.

Informed by the solution’s Vision, Backlog, and Roadmap, practitioners in a DVS define, build, validate, and release solutions to customers, as shown in Figure 1.

Figure 1. A SAFe solution in its context
Figure 1. A SAFe solution in its context

Figure 1 also highlights a solution’s four fundamental properties. Solutions are:

  • Desirable – Do customers and users want the solution?
  • Feasible – Can we deliver the right solution through a combination of build, buy, partner, or acquire endeavors?
  • Viable – Is the way we build and offer the solution creating more value than cost?
  • Sustainable – Are we proactively managing our solution to account for its expected product-market lifecycle?

The remainder of this article describes these four solution properties.

Solutions are Desirable

Solutions are desirable to the portfolio stakeholder who invest in them, the customers who purchase them, and the end-users who interact with them, as described below.

Solutions Deliver the Portfolio’s Value

Enterprises build many solutions and have infinite opportunities to build others. However, just because an organization can build a solution does not mean it should. Portfolio leaders are responsible for determining which solutions best support the portfolio’s strategy.

The Portfolio Vision defines the DVSs that lead to customer solutions and shows how their performance (KPIs) will deliver the portfolio’s objectives defined by the Strategic Themes’ OKRs (Figure 2).

Figure 2. The Portfolio Canvas connects strategy to execution and shows how solutions will deliver the portfolio’s value and realize its objectives
Figure 2. The Portfolio Canvas connects strategy to execution and shows how solutions will deliver the portfolio’s value and realize its objectives

In SAFe, all DVSs build solutions with committed teams and funding (see Lean Budgets) that remain so long as the solution is in operation.

Solutions Deliver Value to Customers

Solutions in SAFe solve a business need, delivering value to an internal or external customer. Some solutions are products the enterprise sells directly to customers. Others may optimize the organization’s internal operations. But every solution has one or more customers who recognize its value.

To build desirable products that connect with customers and address their needs, solution builders apply a Customer-Centric mindset. Some customers are direct, end-users of the solution. Others are indirect customers who pay for and specify the solution but are not users. To understand and empathize with all customers, Solution builders apply Design Thinking to ensure the solution is desirable to all.

Solutions May Support Operational Value Streams

Rapid technology innovations continue to disrupt operational environments. Machines are quickly automating many steps in the Operational Value Stream (OVS), performing them faster and more reliably while reducing costs.

Some solutions directly support an organization’s OVS. For example, a banking operation may provide a mobile application for external customers and call center applications for internal customers. Other solutions are products for a customer’s operational context. For example, an airline uses an aircraft, and many other solutions, in their passenger-delivery operations.

Solutions are Feasible

Most organizations build and deliver products in their domains. Automotive companies provide transportation solutions, and banking organizations offer financial solutions. However, digital disruption allowed businesses to enter and disrupt new markets. For example, Apple outsold the entire Swiss watch industry just four years after launching the Apple Watch. To compete in the digital age, organizations must have the technical knowledge to build innovative solutions and evolve them to meet changing customer and market demands rapidly.

Solution Building Requires Technical Expertise

Building innovative solutions require a diverse range of skills and technical resources. Organizations need the right technical teams, strategic relationships with the right partners, and economic models that ensure that solutions remain feasible over their lifecycles.

To leverage values and practices that continually encourage individuals to increase their knowledge and competence, Lean-Agile enterprises adopt a Continuous Learning Culture. Organizations may partner with suppliers, cultivate competence internally, or both, to fill in gaps. Partnering with suppliers brings domain knowledge, practical experience, and pre-existing solution components to the teams. Note: Organizations are less likely to partner when the supply chain innovates too slowly to support the business strategy or the technology is strategically important. In these cases, competence is developed internally through training, hiring, and strategic acquisition.

Modular Solutions Accelerate Value Delivery

Modular designs that communicate through defined interfaces allow ARTs and teams to evolve their parts of the solution independently and accelerate value delivery. Some solutions provide direct value to an end-user; others are modules (also called components or subsystems) that are parts of a larger solution. Solutions are often built from other solutions to help accelerate value delivery, reduce development costs, and improve quality. Those other solutions come from various sources, including internal and external suppliers and open-source communities (Figure 3).

Figure 3. Solutions may provide direct value to a user or may be part of a larger solution
Figure 3. Solutions may provide direct value to a user or may be part of a larger solution

Architects intentionally decompose solutions into modules that teams and ARTs can independently design and deliver. Modules are:

  • Decomposed: Solutions are split into independent parts that communicate through managed interfaces. Applying a Domain-Driven Design produces solutions that are easier to change, test, and incrementally develop.
  • Nested: Modules may contain other nested modules, resulting in a hierarchy. Layered systems are a common pattern for nesting modules.
  • Integrated: Nested modules are combined for deployment and execution to support all levels of testing and operation. The Continuous Delivery Pipeline (CDP) enables this process.
  • Distributed: Modules may execute on multiple devices or locations to reduce response times, provide higher throughput, provide fault tolerance, and support other Non-Functional Requirements (NFRs).

Some modules are independently releasable elements called value streamlets (see Release on Demand) that teams can independently evolve, deploy, and release without waiting for other teams.

Figure 4. Value streamlets can be independently deployed and released for faster delivery and feedback
Figure 4. Value streamlets can be independently deployed and released for faster delivery and feedback

Solution Intent and Context Define and Evolve the Solution

Solutions have intent and context. The Solution’s Intent defines critical requirements and design constraints, including key decisions. The Solution Context describes aspects of the operational environment for solution installation, usage, and support. Together, intent and context guide the solution’s implementation.

Solution builders apply Lean Systems Engineering and SAFe Principle #3 – Assume variability; preserve options by specifying the solution’s intent and context incrementally. Some decisions, known early in the solution’s lifecycle, are fixed. Others may vary as teams gain knowledge by exploring alternatives using Set-Based Design to find optimal implementations.

Solution intent and context influence the solution’s backlogs and roadmaps in two ways. Fixed decisions drive the work and the backlog items that implement them. Uncertainty also requires work to explore alternatives that can move decisions from variable to fixed. Backlogs contain both types of work to simultaneously build the known parts of the solution while exploring its unknown parts.

Solutions are Viable

The solution’s value to the enterprise must offset the costs of building and operating it (Figure 5). Typically, costs are simple to quantify, including development costs, operating costs, and licensing fees, to name a few. Quantifying value, however, can be trickier. Solutions can provide multiple types of value to the organization:

  • Monetary
  • Improved operations
  • Market share maintenance or expansion
  • New data and insights about consumers and the operational environment
Figure 5. A proper value exchange model ensures viable solutions
Figure 5. A proper value exchange model ensures viable solutions

Whole Product Thinking Ensures Long-Term Viability

To realize the solution’s value, customers need more than great features. They also need excellent service, pre-sales support, documentation, training, reasonable pricing, a promising roadmap from a reputable company, and more. Customers expect these to be part of the overall offering.

As shown in Figure 6, Whole-Product Thinking (see Customer-Centricity) ensures positive experiences throughout all aspects of the customer’s journey — from purchase, to first use, to experienced usage, to upgrades, and even through replacement and decommissioning. Product Management defines the minimal expected product a customer would purchase and the augmented and potential product that differentiates their offering and attracts future customers. The solution’s roadmap forecasts the augmented and potential product features over time.

Figure 6. Whole Product Model
Figure 6. Whole Product Model

Solutions Evolve to Meet Changing Needs

To meet the changing needs of customers and markets, teams must be able to deliver new features quickly, receive feedback, and adjust. A fast, automated Continuous Integration and Continuous Deployment (CI/CD) pipeline provides developers quick feedback on small changes in the development and operations environmental environment. The development environment offers a close, realistic proxy of the operational environment, as shown in Figure 7.

Figure 6. Get faster feedback from development and operational environments
Figure 7. Get faster feedback from development and operational environments

The solution’s vision, backlog, and roadmap include the work to build the CI/CD pipeline. Continuous integration in the development environment provides an economic proxy of the operational environment that can test small changes quickly. However, actual value and feedback can only be evaluated in the operational environment.

Evolving live solutions requires additional constraints. The solution context must provide the ability to deploy changes into live systems and return information from the operational environment. The solution’s design must support the collection of user behavior and the operational environment required for feedback. The solution’s backlog and roadmap also track and forecast this work.

Solutions are Sustainable

Solutions progress through predictable stages, known as the product lifecycle: introduction to growth, growth to maturity, and maturity to decline (Figure 8). Solutions must frequently evolve to move through these stages and address new market segments and customer needs.

Figure 7. Solutions follow a known product lifecycle
Figure 8. Solutions follow a known product lifecycle

The product lifecycle shows why a Lean-Agile approach to developing solutions is critical. Early solutions are Minimal Viable Products (MVP) [3] that generate validated learning to prove or disprove the solution’s business hypothesis (see SAFe’s Lean Startup Cycle in the Epic article). Fast, frequent releases provide new knowledge about the solution’s user, market, and technical decisions to refine its backlog, roadmap, and, occasionally, vision.

As described earlier, the Continuous Delivery Pipeline (CDP) enables the frequent, cost-effective change needed to evolve the solution over its lifecycle.

 


Learn More

[1] Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.

[2] Theodore Levitt. Marketing Success Through Differentiation—of Anything, Harvard Business Review, 1980, https://hbr.org/1980/01/marketing-success-through-differentiation-of-anything

[3] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc, 2011.

 

Last Update: 17 May 2023