Luck is what happens when preparation meets opportunity.
Enablers promote the activities needed to extend the architectural runway to support future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the framework.
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 Large Solution Level, Enabler Features at the Program Level, and Enabler Stories at the Team Level. They can be used for any activities that support upcoming business requirements, but generally fall into one of four categories:
Exploration – Exploration enablers are used for research, prototyping, and other activities needed to develop an understanding of Customer needs, to explore prospective Solutions, and to evaluate alternatives.
Architecture – Architectural enablers are used to build the Architectural Runway, which allows smoother and faster development.
Infrastructure – Infrastructure enablers build, enhance and automate the development, testing, and deployment environments. They facilitate faster development, higher-quality testing, and a faster Continuous Delivery Pipeline.
Compliance – Compliance enablers are used to schedule and manage specific compliance activities, including Verification and Validation (V&V), documentation and signoffs, and regulatory submissions and approvals.
Enablers are the tools that capture information and bring visibility to all the work necessary to support efficient development and delivery of future business requirements. Primarily, they’re used for exploration, architectural Solution evolution, compliance activities, and to enhance development and testing environments (see later sections of this article). Since they reflect the real work (and sometimes plenty of it) they cannot remain invisible. Rather, they’re treated like all other value-added development activities—subject to estimating, visibility and tracking, Work in Process (WIP) limits, feedback, and presentation of results.
Types of Enablers
Enablers exist at all levels of the Framework (and are indicated on the Big Picture in red shading). They assume the attributes of the work they are associated with, as follows:
Enabler epics are written using the recommended Epic hypothesis statement format. They tend to cut across Value Streams and Program Increments (PIs). To support their implementation, they must include a Lean business case and are identified and tracked through the Portfolio Kanban system.
Enabler capabilities and features occur at the Large Solution and Program Levels to capture work of that type. Since these enablers are a type of Feature or Capability, they share the same attributes, including a statement of benefit hypothesis and acceptance criteria. They also must be structured to fit within a single PI.
Enablers are written and prioritized to follow the same rules as their respective epics, capabilities, features, and stories.
Creating and Managing Enablers
Most enablers are created when business initiatives, making their way through the different Kanban systems, require the additional support and elaboration shown below:
- Exploration enablers to validate the need or solution
- Architectural enablers to pave the runway
- Infrastructure enablers to develop, test, and integrate the initiatives
- Compliance enablers to prepare compliance activities
Enablers are often created by architects or by systems engineering at the various levels. They might be Enterprise Architects at the Portfolio Level, or Solution and System Architects/Engineering at the Large Solution and Program Levels. These architects steer their enablers through the Kanban systems, providing the guidance to analyze them, and the information to estimate and implement them.
To improve the existing solution, some enablers will emerge locally from the needs of the Agile Teams, Agile Release Trains (ARTs), or Solution Trains, to ensure that enough emphasis is placed on furthering the solution and extending the Architectural Runway. Those that make it through the Kanban systems will be subject to capacity allocation in the Program and Solution Backlogs. This can be applied for enabler work as a whole, or it can distinguish between different 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. After all, at the beginning of development little is known about what the Customer needs or how to implement it. Customers themselves often don’t understand exactly what they want. Only through iterative product development and demos do they begin to figure out what they actually need.
On the solution side, there are many technical possibilities for how to implement a business need. Those alternatives must be analyzed and are often evaluated through modeling, prototyping, or even concurrent development of multiple solution options (also known as set-based engineering).
The architectural runway is one of the constructs SAFe uses to implement the concepts behind Agile Architecture. The runway is the basis for developing business initiatives more quickly, on appropriate technical foundations. But the runway is constantly consumed by business epics, features, capabilities, and stories; so it must be maintained. Enablers are the backlog items used to maintain and extend the runway.
Some 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, and 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 Program Increment (PI) for the Solution Demo. Many Enterprises implement Continuous Integration and Continuous Deployment to ensure that the solution is always running. This reduces the risk at the integration points, and permits deployment and early release value.
To support such frequent or continuous integration and testing, there’s a need to develop infrastructure at the Team Level, program level, and large solution level. Agile Teams, working with the System Team, are responsible for building and maintenance. 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.
By incrementally building the necessary artifacts in the solution content over a series of PIs, SAFe supports continuous Verification and Validation. Verification activities are implemented as part of the flow (e.g., backlog items or Definition of Done (DoD)). While the artifacts will satisfy the objective evidence needed at the end of development, they are created iteratively throughout the lifecycle. Validation occurs when Product Owners, customers, and end users participate in ART planning and system demos, validating fitness for purpose.
For example, consider that regulations require design reviews, and that all actions need to be recorded and resolved. The design review enabler backlog item offers evidence of the review, and its DoD ensures that actions are recorded and resolved according to the Lean QMS. If needed, the actions themselves could be tracked as enabler stories. Regulations may also require that all changes be reviewed, which is addressed by a compulsory ‘peer review’ DoD for all stories.
Implement Architectural Enablers Incrementally
The size and demands of architectural enabler work can make it overwhelming. So it’s important to remember that it needs to be broken down into small enabler stories that can fit in iterations. This can be difficult, however, 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 so 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 in footnote , 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. In other words, do no harm.
Examples of incremental patterns are also described in footnote , Chapter 2, in which the legacy subsystems are gradually “strangled” over time, using proven patterns such as asset capture or event interception.
By creating the technology platforms that deliver business functionality, enablers drive better economics. But innovative product development cannot occur without risk-taking. Therefore, initial technology-related decisions cannot always be correct. Which is why the Agile enterprise must be prepared to reverse course on occasion. The Ignore-Sunk Costs-principle of product development flow (see footnote , 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. During the analysis phase of the Kanban system, one of the important decisions to make is whether to implement the enabler in all Solution Trains/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 (CoD) caused by not having the full enabler, as Figure 2 illustrates.
Learn More 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: 8 June, 2017