Enablers are a crucial piece of the SAFe® puzzle helping to support agile development practices and get the most from your agile transformation. Find out how in this comprehensive explainer article from Quinn Dodsworth, PM-Partners Agile Learning Consultant and Facilitator and Certified SAFe® 6.0 Practice Consultant (SPC).
Like being quick on your feet, business agility is all about being nimble. And, in today’s complex environment, an enterprise’s ability to adapt at speed is paramount to its long-term success.
The only problem? Building business agility isn’t easy, especially across large organisations. This is where the Scaled Agile Framework® (SAFe®) comes in.
Since Scaled Agile Inc. first launched the SAFe framework in 2011, it has become one of the most widely used approaches for implementing agile principles. Unsurprisingly, it’s the most popular choice among enterprises, as it allows them to scale their agile transformation across the entire business.
Scaled Agile has much to offer, but you risk undercutting its benefits without SAFe enablers. To explain, let’s explore what enablers are, why they’re important and how they support agile development.
What is an enabler?
Scaled Agile Inc. defines enablers as product backlog items that establish an effective ‘architectural runway’ for any solution under development. The term architectural runway refers to all existing code, components or technical infrastructure needed to implement features with minimal delay, providing a continuous flow through the delivery pipeline.
Moreover, enablers also include any backlog items that improve the development value stream — which represents one or more solutions that address the business mission and vision. Although they don’t directly deliver value, they do ultimately result in the production of tangible outputs by facilitating the delivery process.
In simple terms, enablers are the building blocks that help an agile team work more effectively by fixing technical problems and inefficiencies that would otherwise weigh the development process down. These could include:
- Technical debt
- Infrastructure challenges
- Dependencies between teams, systems and components
- Scalability issues
- Compliance requirements.
Enablers function in the Scaled Agile Framework as a form of upkeep, much like servicing a car. Maintenance activities ensure everything runs smoothly, safely, and sustainably. But, without upkeep, you run the risk of encountering major breakdowns like those listed above.
4 types of enablers
Enablers are used to experiment with ideas, make improvements and manage compliance. They’re treated the same as all other backlog items and are subject to visibility, prioritisation, incremental delivery, measurement and feedback.
According to the Scaled Agile Framework, enablers fall into four categories:
1. Exploration enablers
Exploration enablers are activities aimed at gaining a better understanding of end-user needs. They give agile team members a chance to discover a product’s key design details and requirements or experiment with alternative solutions to any given problem.
This is especially important at the beginning of an agile development cycle. At this point, exact design requirements are still unknown. Building prototypes and conducting research, for example, are explorational enablers that allow project teams to overcome their uncertainties. Releasing a prototype — otherwise known as a minimum viable product (MVP) — is an opportunity to gather feedback from users and decide on next steps.
2. Architectural enablers
As the name suggests, this type of enabler is used to build an architectural runway — and with that, improve product delivery.
Using agile architecture principles, enablers define a technical development framework across every agile release train (ART) down to the team level. In turn, they include all activities, behaviours or tools that enhance future value streams.
Architectural enablers are important because they ultimately lead to faster planning intervals (PIs). Not only do they help ARTs reach their PI objective efficiently, but they also ensure high-quality outcomes.
For example, a software development team may implement a microservices architecture. This involves breaking down a monolithic application into smaller, independently deployable services, each responsible for a specific feature or business capability. This allows the team to develop and deploy features more quickly and independently, supporting agile development practices within the Scaled Agile Framework.
3. Infrastructure enablers
Fundamentally, agile development is based on how frequently the agile release train can integrate, deploy and release products and solutions to end users. This involves various environments where teams can develop and test their work.
Therefore, infrastructure enablers are a type of work item that reduces the effort required to do exactly that. For example, teams may create an automated continuous integration/continuous deployment pipeline. By eliminating manual work, it generates a faster development lifecycle and makes it easier to deploy a new planning interval.
4. Compliance enablers
A compliance enabler is an item that facilitates specific compliance activities, such as verification and validation (V&V), audits and approvals or policy automation.
Take V&V, for instance. Whereas verification continuously checks that in-progress work meets certain standards, validation is when a product owner or end user checks that it does what it’s supposed to do during a system demo or ART planning session.
Agile teams use compliance enablers to support these activities. Let’s say all designs must be reviewed and documented. In this case, a product backlog item called ‘design review’ provides visibility and evidence that this requirement has been met.
So, why do compliance enablers matter? Because they ensure development teams and stakeholders are aligned on expectations. For example, the ‘definition of done’ is an artefact that allows the product owner to define customer expectations, which helps the rest of the team understand what a quality outcome should look like.
Creating SAFe® enablers
Whether in a portfolio, program, or product backlog, enablers are represented as epics, features, capabilities and stories. They’re created and managed using the same basic rules for each of these items, ensuring consistency and alignment across the SAFe framework.
But what are epics, features, capabilities and stories? Let’s explore each one individually and how they work in the context of SAFe enablers.
Epics
According to Scaled Agile, an epic — also known as a business epic — is a significant solution development initiative. In other words, it’s a large body of work that can be broken down into smaller tasks. They typically represent major organisational initiatives that are too large to complete in a single iteration or sprint.
Enabler epics are very similar to their business counterparts. Both require an ‘epic hypothesis statement’, which is a full description of future business functionality and spans multiple ARTs and PIs.
However, enabler epics specifically focus on addressing technical or architectural challenges rather than directly delivering business value. In short, they offer a strategic roadmap for navigating organisational issues, such as addressing technical debt or improving infrastructure.
Typically, the epic owner would take responsibility for creating business epics, whereas architects normally guide their supporting enabler epics. This includes enterprise architects supporting the portfolio, systems architects supporting ARTs and solution architects supporting the solution train.
Features and capabilities
Features and capabilities play similar but different roles within the Scaled Agile Framework. A feature represents a solution functionality that delivers business value or fulfils a stakeholder’s need. Each feature includes a benefit hypothesis and acceptance criteria and is specifically sized to be delivered by a single agile release train.
Capabilities serve a similar purpose but exist on a bigger scale. In other words, a capability represents large solution functionality and its implementation may span multiple ARTs.
Likewise, enabler features and enabler capabilities follow the same rules, requiring both a benefit hypothesis and acceptance criteria. Also, they must fit within a single PI objective and are each defined by ARTs and solution trains. However, rather than representing functionality that directly delivers value, enabler features/capabilities focus on building the technical foundation required to make delivery fast and effective.
Identifying and creating these enablers is normally the responsibility of the system architect or solution architect. Some enabler features may originate from epics or emerge at the ART level.
Stories
In SAFe, a user story is a short description of how a particular feature or functionality should behave from an end-user perspective. Stories are the primary artefact agile teams use to define system behaviour, each one implementing a slice of functionality in a few days or less. In turn, they’re often the smallest work item in agile development. According to Scaled Agile, enabler stories emerge locally from the agile team’s needs and are carried in the team backlog.
Whereas a user story delivers functionality directly, an enabler story brings visibility to the technical work items needed to support exploration, architecture, infrastructure and compliance. Therefore, enabler stories don’t have to be written from the user’s perspective. Like any story, they must also fit within the iteration of the individual agile team. Their acceptance criteria — set by the product owner — should clarify the requirements and support testing.
Enable a SAFe® transformation
Enablers are key building blocks in the Scaled Agile Framework that not only impact the delivery lifecycle but ensure your agile transformation is working its magic. By addressing critical dependencies, infrastructure needs and architectural concerns, enablers help organisations avoid critical issues and save long-term costs. Identifying and mitigating these potential roadblocks improves team performance, allowing maximum value to flow seamlessly and efficiently from beginning to end.
Just starting your implementation? Try one of PM-Partner’s SAFe courses to begin your education. Or, to advance your journey, leverage our SAFe consultation services.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.