Enabling Areas
Cross-functional delivery teams own their products end-to-end. But some capabilities are best developed and maintained as shared functions that support teams across the organization — rather than being rebuilt independently in every team.
These shared functions are enabling areas. They do not own delivery. They build the conditions that make delivery better.
What Enabling Areas Do
Each enabling area has the same fundamental logic:
- Develops and maintains shared principles, guidelines, and reference models in its domain
- Provides specialist support when teams face complex problems beyond their own expertise
- Builds organizational capability through communities of practice and coaching
- Ensures coherence across the system — not uniformity, but a shared foundation
Enabling areas work with teams. They do not gate, control, or direct team decisions. A team that does not need support from an enabling area in a given interval is working as intended. The enabling area’s influence shows up in the quality and consistency of team decisions — not in approval processes.
Architecture
Architecture at this level maintains the reference architecture, technical principles, and architectural guidelines that teams use as the context for their own design decisions.
Teams make local design decisions. The architecture enabling area ensures those decisions are made within a coherent whole — that technical choices across value streams remain compatible and the system can evolve without accumulating structural debt.
The architecture function also engages with teams facing questions that require broader perspective: cross-value-stream integration, platform direction, long-term technical evolution. Intentional architecture and emergent design coexist — the enabling area holds the intentional layer.
Quality and Testing
The quality enabling area drives test strategy across the organization, builds shared test environments and automation infrastructure, and supports teams in developing their own testing capability.
End-to-end and integration testing — the testing that crosses team or value stream boundaries — is owned jointly by the value stream, defined by the QA function, and automated in collaboration with the CI/CD area.
Built-in quality is the principle: quality is the team’s responsibility from the first line of code. The enabling area builds the competence and infrastructure that makes that responsibility achievable.
CI/CD and Cloud
The CI/CD and cloud enabling area provides the delivery infrastructure that teams build on: shared pipelines, deployment tooling, environment management, and observability infrastructure.
Self-service is the operating model. Teams should be able to set up environments, deploy, and observe their systems without manual intervention from a central team. The enabling area designs and maintains the infrastructure that makes self-service possible.
Pipelines are treated as an internal product — maintained, versioned, and improved continuously. Teams are customers of that product.
UX and Customer Experience
The UX enabling area maintains the design system, UX guidelines, and experience standards that create consistency across the user-facing product.
UX practitioners work closely with product teams — embedded or shared — bringing user insights, prototypes, and design improvements directly into delivery. The enabling area coordinates across those embedded practitioners to maintain coherence at the system level and prevent fragmentation of the user experience.
Agile Enablement
The agile enablement area supports teams and leadership in continuously developing their ways of working. Its focus is building capability — not enforcing process.
Agile coaches and change practitioners work with teams on continuous improvement, facilitate organizational change initiatives, and develop communities of practice where practitioners learn from each other across value streams.
The measure of success for agile enablement is the improvement in the teams it works with — not the volume of activity it produces.