Luck is what happens when preparation meets opportunity.
Enablers are technical initiatives meant to enable and support the development of business initiatives. Enablers (reflected in red on the Big Picture) exist on all four levels of SAFe: Enabler Epics at the Portfolio Level, Enabler Capabilities at the Value Stream Level, Enabler Features at the Program Level, and Enabler Stories at the Team Level. Enablers can be used for any activities that are necessary to support upcoming business features, but generally they fall into one of three categories:
- Exploration – Exploration enablers are used to build understanding of what is needed by the Customer, to understand prospective Solutions, and to evaluate alternatives
- Architecture – Architectural enablers are used to build the Architectural Runway in order to enable smoother and faster development
- Infrastructure – Infrastructure enablers are used to build and enhance the development and testing (and occasionally deployment) environments, thereby facilitating faster development and higher-quality testing
Enablers are work items that capture and bring visibility to all the work necessary to support efficient development and delivery of future business Features. They are used primarily for exploration, system and Solution architectural evolution, and to enhance development and testing environments (see later sections of this article). Since they reflect real work, and sometimes plenty of it, they cannot be invisible. They are treated like all other value-added development activities and are thereby subject to estimating, visibility and tracking, WIP limits, feedback, and, finally, presentation of results.
Types of Enablers
Enablers exist at all levels of the framework (and are indicated on the Big Picture by red shading). They inherit the attributes of the type of work they are associated with, as follows:
- Enabler epics are a type of Epic, and as such are written using the value statement format defined for epics. They tend to cut across Value Streams and Program Increments (PIs). They must include a lightweight business case to support their implementation and are identified and tracked through the Portfolio Kanban system.
- Enabler capabilities and features occur at the Value Stream and Program Levels, where they capture work of that type. As these enablers are a type of Feature or Capability, they share the same attributes, including a statement of benefits and acceptance criteria, and they must be structured so as to fit within a single PI.
- Enabler stories, as a type of Story, must fit in Iterations. However, while they may not require user voice format, they have acceptance criteria to clarify the requirements and support testing.
Enablers are written, prioritized and follow the same rules as their respective epics, capabilities, features, and stories. For example: Features and enabler features are written using a Features and Benefits matrix, have acceptance criteria, use story points for estimation and WSJF for prioritization, etc.
Creating and Managing Enablers
Most enablers are created when business initiatives, making their way through the different Kanban systems, require exploration enablers to validate the need or solution; architectural enablers to pave the runway; or infrastructure enablers to be ready to develop, test, and integrate the initiatives.
Enablers are often created by architects or by systems engineering at the various levels, whether by Enterprise Architects at the Portfolio Level or by Solution and System Architects/Engineering at the value stream and program levels. The architects who create the enablers steer them through the Kanban systems, providing both the guidance needed to analyze them and the information needed to estimate and implement them.
Some enablers will emerge locally from the needs of the Agile Teams, Agile Release Trains (ARTs), or value streams to improve the existing solution. Enablers that make it through the Kanban systems will be subject to capacity allocation in the Program and Value Stream Backlogs to ensure that enough emphasis is placed on both, furthering the solution and extending the Architectural Runway. Capacity allocation can be applied for enabler work as a whole or it can differentiate between the various types of enablers.
Applying Enablers for exploration provides a way for development teams to flesh out the details of requirements and design. The nature of Solution Intent is that many requirements begin as variables, since at the beginning of development little is known about exactly what the Customer needs or how to implement it. Often the customers themselves don’t understand exactly what they want, and only through iterative product development and demos do they gain an understanding of what they actually need.
On the solution side, there are many technical possibilities for how to implement a business need. These alternatives need to be analyzed and sometimes evaluated through modeling, prototyping, or even concurrent development of multiple solution options (set-based engineering).
The architectural runway is one of the means by which SAFe implements the concepts of Agile Architecture. The runway provides the basis for developing business initiatives more quickly, on appropriate technical foundations. But the runway is constantly consumed by business epics, features and capabilities, and stories, and so it must be constantly maintained. Enablers are backlog items used to extend the runway.
Some of these architectural enablers fix existing problems with the solution—for example, the need to enhance performance. These enablers start out in the backlog, but after implementation, they may become Nonfunctional Requirements (NFRs). In fact, many NFRs come into existence as a result of architectural enablers. They tend to build over time, as can be seen in Figure 1.
Agile development is built on frequent integration. Agile Teams integrate their work with other teams on the ART at the System Demos in every iteration. The trains integrate every PI for the Solution Demo. Many Enterprises even implement Continuous Integration to ensure that the solution is always running and to reduce the risk at the integration points.
To support these frequent or continuous integration and testing constructs, there is a need to develop infrastructure at the Team Level, program level, and value stream level. New infrastructure is also sometimes needed to increase the rate of Release to the Customer. Agile Teams, working with the System Team, are responsible for building and maintaining this infrastructure. Infrastructure enablers are used as backlog items to advance this work and continuously enhance it, both to support new scenarios and to enhance the agility of the enterprise.
Implement Architectural Enablers Incrementally
Architectural enabler work can be big. It is important to remember that it needs to be broken down into small enabler stories that can fit in iterations. This can be difficult, as architectural and infrastructure changes can potentially stop the existing system from working until the new architecture/infrastructure is in place. When planning enabler work, make sure to organize it such that the system can run for most of the time on the old architecture or infrastructure. That way teams can continue to work, integrate, demo, and even release while the enabler work is happening.
As described in System and Solution Architect/Engineering and , there are three options:
- Case A: The enabler is big, but there is an incremental approach to implementation. The system always runs.
- Case B: The enabler is big, but it can’t be implemented entirely incrementally. The system will need to take an occasional break.
- Case C: The enabler is really big, and it can’t be implemented incrementally. The system runs when needed; do no harm.
Examples of incremental patterns are also described in  (Chapter 2), whereby the legacy subsystems are gradually “strangled” over time, using proven patterns such as asset capture or event interception.
Enablers drive better economics by creating the technology platforms that deliver business functionality. But innovative product development cannot occur without risk-taking. Therefore, initial technology-related decisions cannot always be correct. Hence the Agile enterprise must be prepared to reverse course on occasion. The Ignore Sunk Costs principle of product development flow (, principle E17) provides essential guidance: Do not consider money already spent. Incremental implementation helps, as corrective action can be taken before the investment grows too large.
Plan Cross-ART and Cross-Value Stream Enablers
Enabler epics and enabler capabilities can cut across multiple value streams or ARTs respectively. During the analysis phase of the Kanban system, one of the important decisions to make is whether to implement the enabler in all VSs/ARTs at the same time or to do so incrementally. This is a trade-off between the risk reduction of implementing one solution or system at a time vs. the cost of delay caused by not having the full enabler, as Figure 2 illustrates.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
 Fowler, Martin. Strangler Application. http://martinfowler.com/bliki/StranglerApplication.html.
 Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
Last update: 21 April 2016