Continuous attention to technical excellence and good design enhances agility.
Team and Technical Agility
Team and Technical Agility (TTA) is one of the seven core competencies of Business Agility. Each core competency is supported by a specific assessment, which enables the enterprise to assess its proficiency. The core competency assessments, along with recommended improvement opportunities, are available from the Measure and Grow article.
Why Team and Technical Agility?
Agile Teams create and support the business solutions that deliver value to the enterprise’s customers. Consequently, an organization’s ability to thrive in the digital age is entirely dependent on the ability of its teams to deliver solutions that reliably meet customers’ needs. Team and technical agility is the real cornerstone of Business Agility. It consists of three dimensions, as illustrated in Figure 1.
- Agile Teams – High-performing, cross-functional teams anchor the competency by applying effective Agile principles and practices.
- Teams of Agile Teams – Agile teams operate within the context of an Agile Release Train (ART), a long-lived team of Agile teams that provides a shared vision and direction and is ultimately responsible for delivering solution outcomes.
- Built-In Quality – All Agile teams apply defined Agile practices to create high-quality, well-designed solutions that support current and future business needs.
These three dimensions are complementary and dependent forces that organize and guide the people who power the value stream.
The Agile team is the basic building block of Agile development and is the first dimension of the TTA competency. An Agile team in SAFe is a cross-functional group of 10 or fewer individuals who iteratively define, build, test, and deliver value to their customers. These teams have the authority and accountability to manage their work, which increases productivity and accelerates time-to-market.
Each Agile team adopts SAFe Scrum, SAFe Team Kanban, or a hybrid method to regulate their synchronization and delivery cadence. They apply the chosen method to manage a shared backlog, deliver incrementally, build necessary Architectural Runway, and obtain frequent customer and stakeholder feedback.
An Agile team’s primary objective is to deliver great products. As shown in Figure 2, they accomplish this by focusing on five key areas of responsibility.
Each of these areas of responsibility is summarized below.
- Connecting with the customer – Agile teams understand their customers’ specific needs and use that knowledge to guide product development. They build empathy with customers and use that knowledge to collaborate with Product Management on product design and solution experiments.
- Planning the work – Agile teams plan their work and contribute directly to PI Planning. They maintain their Team Backlog, calibrate their priorities during Iteration Planning and Backlog Refinement, play a central role in PI Planning, and link their work to items in the ART Backlog.
- Delivering value – Agile teams possess all the skills and resources required to deliver great products that delight their customers. They maintain alignment with the ART through various synchronization events and demos and establish Continuous Delivery Pipelines that enable them to frequently integrate, test, deploy, and release changes.
- Getting feedback – Agile teams seek feedback from customers regularly to understand the value of the products and technology delivered. They find pathways to feedback that shorten the distance between them and their customers and continuously validate implementation decisions with other teams and architects.
- Improving relentlessly – Agile teams track the flow, competency, and outcome metrics that gauge their performance and contribute to business agility. They use these measurements to continually fuel retrospectives, define new performance targets, and implement improvements.
The Agile Manifesto guides Agile teams as they carry out their responsibilities (Figure 3). Although originally envisioned for software teams, these values apply to all types of Agile teams throughout technology and business.
Value delivery often spans traditional organizational boundaries. Therefore, Agile teams are multidisciplinary, containing all the people and skills needed to deliver value across functional domains, as depicted in Figure 4. Team members are dedicated full-time to the team, which creates a shared purpose and enhances flow.
Agile teams have two specialty roles (Figure 4). The Product Owner ensures that the Team Backlog is aligned with customer needs and guides the team toward delivering maximum business value. The Scrum Master/Team Coach is a servant leader and coach for the team, facilitating the agreed-to Agile process and fostering an environment that enables fast flow.
Each Agile team maps to one of the following four topologies, specifying the team’s role in the value stream.
- Stream-aligned team – An Agile team organized around the flow of work that can deliver value directly to the customer or end user.
- Complicated subsystem team – An Agile team organized around specific subsystems that require deeply specialized skills and expertise.
- Platform team – An Agile team organized around developing and supporting platforms that provide services to other teams.
- Enabling team – An Agile team organized to assist other teams with developing proficiency with new skills or technologies.
Teams of Agile Teams
Building enterprise-class solutions require more scope and breadth of skills than a single Agile team can provide. No one team can build and deliver large systems within a reasonable timeframe. And complex systems require a broad range of specialized skills that cannot be contained within a single team. Therefore, multiple Agile teams collaborate as members of an Agile Release Train, which operates across business functions to deliver one or more solutions (Figure 6).
Organized around one or more value streams, ARTs align teams to a common business and technology mission. They exist to deliver valuable solutions to their customers, which requires a broad spectrum of skills applied to five primary areas of responsibility (Figure 7).
The ART’s areas of responsibility are identical to those of the Agile team. However, the ART applies them at scale, throughout the value stream, to deliver integrated solutions with compelling business value. And, like Agile teams, ARTs plan together, commit together, execute together, and improve together.
Built-In Quality is a set of practices that ensures that the outputs of Agile teams and ARTs meet appropriate quality standards. These practices favor building quality into products and services during development rather than simply inspecting for quality before release. Building quality in reduces the effort and cost associated with rework in the value stream, significantly accelerating value delivery.
As illustrated in Figure 8, built-in quality consists of several specialized practices organized into five primary domains. The remainder of this section summarizes these elements.
Quality is evaluated and applied differently in different contexts. The same engineering standards would not govern a multi-player online game as a dialysis machine. Similarly, the development of a merger or acquisition agreement would be constrained by different quality requirements than an autonomous vehicle navigation system. SAFe organizes built-in quality practices into five domains to account for these major differences in context:
- Business functions – HR, marketing, finance, sales, and other disciplines that do not engineer technology-enabled solutions as a primary function are governed by quality standards that are unique to their fields. Examples could include accounting standards, marketing style guides, and employment laws.
- Software applications – Developing software-based solutions with built-in quality involves careful attention to functional, non-functional, and compliance requirements.
- IT systems – The infrastructure upon which software-based solutions operate must be designed with the scalability, reliability, and security needed to provide sustained business value.
- Hardware – Unlike purely digital products, hardware-based solutions have physical features that must conform to specific weight, tension, heat, thrust, electrical, or other engineering specifications.
- Cyber-physical systems – Systems comprising a multitude of hardware components controlled by complex software routines—such as automobiles and aircraft—involve a complex array of quality standards that large teams of teams must address.
Working within these domains, Agile teams and ARTs apply specific practices early in the development cycle to ensure that quality is built into every product increment. Some practices apply across domains, while others are optimized for a single domain, as explained below.
- Basic Agile quality practices – These practices apply to all domains. They are the foundational building blocks of built-in quality and include techniques such as shifting learning left, pairing, peer review, collective ownership, and workflow automation.
- Business quality standards – These practices are unique to the business functions domain and typically address industry-specific standards and regulations outside IT. For example, legal teams may be bound by specific local and regional laws. HR teams may need to conduct business under strict privacy regulations.
- Agile software development quality practices – These practices apply to the development of any software-enabled solution. Continuous integration, test-first development, refactoring, and Agile architecture are some of the techniques in this category that enable built-in quality and streamline the delivery of digitally enabled solutions.
- IT systems quality practices – Implementing infrastructure-as-code, telemetry, observability, and automated governance, for example, helps build quality into the infrastructure that hosts the business’s applications.
- Agile hardware engineering quality practices – These practices apply to developing hardware-based solutions. The cost of change can be extremely high with these solutions, but modeling, simulation, and rapid prototyping help to assure quality and avoid expensive rework.
- Cyber-physical systems quality practices – Building quality into many of the world’s most complex systems is not trivial but is made easier with model-based systems engineering (MBSE) and frequent, end-to-end system integration.
These practices are mixed and matched appropriately to ensure all elements of a solution are developed with high quality and can be delivered in the shortest sustainable lead time. More detail can be found in the Built-In Quality article.
As explained by Principle #6 – Make value flow without interruptions, SAFe is a flow-based system that promotes fast, efficient value delivery. Flow is present when Agile teams, ARTs, and the portfolio can deliver high-quality products and services with minimal delay.
To accelerate flow throughout the value stream, wasteful activities are continuously detected and remediated at all levels of SAFe. In particular, the TTA competency enables Agile teams to quickly identify inefficiencies in their part of the value stream that can then be corrected using the flow accelerators described in the Team Flow article. The more proficient teams become with TTA, the faster they detect and correct flow issues.
TTA also contributes to an ART’s ability to accelerate flow; however, the Agile Product Delivery competency enables ART Flow more directly.
TTA enables cross-functional Agile teams to accelerate value delivery without being bound to any specific way of working. This promotes long-lived teams that learn together, grow together, and deliver great products. ARTs comprise several Agile teams, are too cross-functional and can cover the complete solution delivery life cycle. Agile teams and ARTs are mutually responsible for building quality into everything they deliver. The result is an organization with the team and technical agility required to deliver continuous value at an enterprise scale.
 Manifesto for Agile Software Development. AgileManifesto.org
Last update: 14 March 2023