Luck is what happens when preparation meets opportunity.

    —Widely attributed to Seneca, Roman philosopher and playwright

    Enablers

    Definition: Enablers are backlog items that extend the architectural runway of the solution under development or improve the performance of the development value stream.

    Enablers are captured in backlogs as a type of Epic, Capability, Feature, or Story. They are used primarily for exploration, architecture implementation, refactoring, building infrastructure, and addressing compliance. While their type is unique, they are managed similarly to customer-facing backlog items.

    Details

    Enablers bring visibility to all the work necessary to support the efficient development and delivery of future business requirements. Enablers are used to explore ideas, improve architecture, strengthen infrastructure, and manage compliance. Since enablers result in the production of tangible outputs, they must be visible. They are treated like all other backlog items—subject to visibility, prioritization, incremental delivery, measurement, and feedback.

    Types of Enablers

    Enablers can be used to define any activity that improves the value stream in support of foreseeable business needs. These activities generally fall into one of four categories:

    • Exploration – support research, prototyping, and other activities needed to develop an understanding of customer needs, including the exploration of prospective Solutions and evaluation of alternatives
    • Architectural – used to build Architectural Runway, which allows smoother and faster development through the Continuous Delivery Pipeline (CDP)
    • Infrastructure – support the creation and optimization of the development and runtime environments that host the systems used to build, validate, deploy, and operate solutions
    • Compliance – facilitate managing specific compliance activities, including Verification and Validation (V&V), audits and approvals, and policy automation

    Creating and Managing Enablers

    Enablers exist throughout SAFe and are written and prioritized according to the same rules as their corresponding epics, features, capabilities, and stories.

    • Enabler Epics – These are written using the ‘epic hypothesis statement’ format, in the same way as business epics. Enabler epics can span multiple Agile Release Trains (ARTs) and PIs and are managed via the Portfolio Backlog and associated Kanban system.
    • Enabler Features and Capabilities – These are defined by ARTs and Solution Trains and include a short phrase, benefit hypothesis, and acceptance criteria. They must be sized to fit within a single PI.
    • Enabler Stories – Must fit within Iterations like any story. Although they may not require the user voice format, their acceptance criteria clarify the requirements and support testing.

    Architects often define and guide enabler epics, features, and capabilities. They might be Enterprise Architects supporting the portfolio, System Architects supporting ARTs, or Solution Architects supporting Solution Trains. Architects steer enablers through the appropriate Kanban system and backlog, guiding implementation from concept to delivery. Agile Teams also use enablers; enabler stories emerge locally from their needs and are carried in the Team Backlog.

    The following examples illustrate how Agile teams and architects create and manage each of the four enabler types.

    Enabling Exploration

    Exploration enablers provide work items teams can use to discover requirements and design details. The nature of Solution Intent is that many requirements begin as variable intent. At the beginning of development, little is known about what the customer needs or how to implement it. Customers themselves often don’t understand precisely what they need. Through Continuous Exploration, teams progressively learn which aspects of solution intent should move from variable to fixed.

    In an even broader view, there are typically many technical possibilities for implementing an identified business need or opportunity. Those alternatives must be analyzed and are often evaluated through modeling, prototyping, Set-Based Design, or the Lean Startup Cycle. Exploration enablers formalize these activities, assure that the work is visible,  and help ensure solution development is closely aligned with the needs of customers and stakeholders.

    Enabling Architecture

    In SAFe, Agile Architecture practices produce architectural runway, the underlying technology that enables Agile teams and ARTs to deliver business solutions quickly. But the runway is constantly consumed by business epics, features, capabilities, and stories, so it must be extended for new functionality. Architectural enablers are used to build, extend, and maintain the runway.

    Architectural enablers can also address problems with the resiliency of deployed solutions. After implementation, these enablers often reflect Nonfunctional Requirements (NFRs) imposed on future backlog items. NFRs often originate as architectural enablers and grow as a set over time (Figure 1).

    Figure 1. Many NFRs appear over time as a result of enablers
    Figure 1. Many NFRs appear over time as a result of enablers

    Enabling Infrastructure

    Agile development requires frequent integration. Agile teams integrate their work and showcase the working solution increment at the System Demo. Similarly, ARTs that are part of a Solution Train integrate their work as frequently as possible during the PI in preparation for Solution Demos. Infrastructure enablers provide the Continuous Integration and Continuous Deployment technology that supports this aggressive integration cadence.

    The System Team is integral in defining and building infrastructure enablers that enhance the development environment and streamline the CDP. Shared Services, Operations teams, and Site Reliability Engineering (SRE) leverage infrastructure enablers to deliver Cloud services that accelerate solution development and solution scalability.

    Enabling Compliance

    By incrementally building the necessary artifacts in the solution intent over a series of PIs, SAFe supports continuous verification and validation. Verification activities are conducted as part of the development workflow and are often enforced in the Definition of Done (DoD). While the artifacts will satisfy the objective evidence needed at the end of development, they are created iteratively throughout the life cycle. Validation occurs when Product Owners, customers, and end-users participate in ART planning and system demos, validating fitness for purpose.

    Enablers are used to support these activities. For example, consider a regulation that requires design reviews and that all actions stemming from those reviews must be documented when completed. A ‘design review enabler’ backlog item would offer evidence of the review, and its DoD would ensure that actions are recorded and resolved according to the Lean Quality Management System (QMS). If needed, the activities themselves could be tracked as enabler stories.

    Implementing Enablers Incrementally

    Enablers supply critical, foundational technology and insight into the value stream. Consequently, they deserve focused attention in the portfolio, from budgeting and capacity allocation through delivery and ongoing improvement. But because the actual value of enablers is tied to the realization of future business objectives, care must be taken to implement enablers quickly and iteratively. Otherwise, delivering value to customers can be significantly delayed, undermining the fundamental purpose of enablers.

    Enablers of all types should be implemented incrementally. However, because architectural and infrastructure enablers often influence the delivery and operation of mission-critical solutions, they deserve special mention here.

    The size and demands of architectural and infrastructure enabler work can be overwhelming. So, it’s important to remember that they need to be split into features and stories that can be delivered incrementally. This can be difficult, however, as architectural and infrastructure changes can potentially stop the existing system from working until the changes are in place.

    The work must be sequenced to ensure the system can continue operating in the current environment while enablers are implemented. That way, teams can continue to work, integrate, demo, and even release new functionality.

    There are three ways to approach this [1]:

    • Case A – The enabler is big, but there is an incremental approach to implementation. The system always runs (operates).
    • Case B – The enabler is big but can’t be implemented 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.

    Examples of incremental patterns are also described in [2], where 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 Lean enterprise must be prepared to change course occasionally. In these cases, the principle of sunk costs [3] provides essential guidance: Do not consider money already spent. Implementing incrementally allows corrective action before the investment grows too large.

    Implementing Enablers Across ARTs and Value Streams

    Enabler epics and capabilities can cut across multiple value streams or ARTs. During the analysis stage of the appropriate Kanban system, it is important to determine whether to implement the enabler across all ARTs simultaneously or incrementally (Figure 2).

    Figure 2. Two approaches to implementing cross-cutting enablers
    Figure 2. Two approaches to implementing cross-cutting enablers

    In scenario A, the enabler is implemented first in ART 1, then by the other ARTs in subsequent PIs. This may lessen the impact of the change across the portfolio but can delay the full benefits of a fully implemented enabler. By contrast, scenario B calls for all ARTs to implement the enabler at the same time. This is preferable if the cost of delaying the entire implementation is unacceptably high.

    Learn More

    [1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010.

    [2] Fowler, Martin. Strangler Fig Application. MartinFowler.com, June 29, 2004. Retrieved October 13, 2023, from http://martinfowler.com/bliki/StranglerApplication.html

    [3] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

    Last update: 13 October 2023