Luck is what happens when preparation meets opportunity.
—Seneca
Enablers
An Enabler supports the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, architecture, infrastructure, and compliance. Enablers are captured in the various backlogs and occur throughout the Framework.Details
Enablers bring visibility to all the work necessary to support efficient development and delivery of future business requirements. Primarily, enablers are used for exploration, evolving the architecture, improving infrastructure and compliance activities. Since enablers reflect real work they cannot remain invisible. Instead, 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.
Type of Enablers
Enablers can be used for any activities that support upcoming business requirements and generally fall into one of four categories:
- Exploration enablers – These support research, prototyping, and other activities needed to develop an understanding of customer needs, including the exploration of prospective Solutions and evaluating alternatives.
- Architectural enablers – These are created to build the Architectural Runway, which allows smoother and faster development.
- Infrastructure enablers – These are created to build, enhance, and automate the development, testing, and deployment environments. They facilitate faster development, higher-quality testing, and a faster Continuous Delivery Pipeline.
- Compliance enablers – These facilitate managing specific compliance activities, including Verification and Validation (V&V), documentation and signoffs, and regulatory submissions and approvals.
Creating and Managing Enablers
Enablers exist throughout the Framework and are written and prioritized to follow the same rules as their corresponding epics, capabilities, features, and stories.
- Enabler Epics – Are written using the ‘Epic Hypothesis Statement’ format, in the same way as business epics. Enabler epics typically 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 Features and Capabilities – Defined by Agile Release Trains (ARTs) and Solution Trains . Since these enablers are a type of Feature or Capability, they share the same attributes, including a short phrase, benefit hypothesis and acceptance criteria. They also must be sized to fit within a single PI.
- Enabler Stories – Must fit in Iterations like any Story. Although they may not require the user voice format, their acceptance criteria clarify the requirements and support testing.
Enablers are often created by architects or by engineering. They might be Enterprise Architects supporting the portfolio backlog, or System and Solution Architects/Engineers supporting ARTs and Solution Trains. Architects steer 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, 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
Exploration
Applying enablers for exploration provides a way for Agile teams to discover the details of requirements and design. The nature of Solution Intent is that many requirements begin as variable intent. 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 need and the solution intent can become fixed.
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 Design).
Architecture
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) which can be considered constraints on new development. 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.
Infrastructure
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 that are part of a Solution Train integrate every PI as part of 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.
The System Team assists one or more ARTs in building and using the Agile development environment infrastructure—including the continuous delivery pipeline toolchain—as well as integrating assets from Agile teams. Infrastructure enablers are used as backlog items to advance this work, both to support new user scenarios and to enhance the agility of the enterprise.
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 implemented as part of the normal workflow (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 life cycle. 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 often 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 Quality Management System (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 smaller stories that fit in an iteration. 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 operate 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 [1], there are three options:
- 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 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 [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 on occasion. In these cases, the principle of sunk costs [3] provides essential guidance: Do not consider money already spent. Incremental implementation helps, as the corrective action can be taken before the investment grows too large.
Implement Enabler Epics Across ARTs and Value Streams
Enabler epics and enabler capabilities can cut across multiple value streams or ARTs. During the analysis phase of the appropriate 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 versus the Cost of Delay (CoD) caused by not having the full enabler, as Figure 2 illustrates.
Learn More
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011. [2] Fowler, Martin. Strangler Application. http://martinfowler.com/bliki/StranglerApplication.html [3] Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
Last update: 10 February 2021
