Home » Team and Technical Agility Discipline

Team and Technical Agility

The Team and Technical Agility Discipline describes how to enable cross-functional Agile Teams to accelerate value delivery. It describes the critical skills, roles, and practices that high-performing Agile Teams and Agile Release Trains (ARTs) use to create high-quality products and solutions for customers. All Agile Teams and ARTs are responsible for building quality into everything they deliver. The result of applying this discipline across all of product development, engineering, and delivery is an organization with the team and technical agility required to deliver continuous value at scale

Figure 1 shows the elements, processes, and outcomes of the Team and Technical Agility described within this discipline of SAFe. Click on the icons to learn more.

Scrum Master / Team CoachVisionRoadmapWSJFART BacklogNonfunctional RequirementsART BacklogSystem TeamAgile TeamsProduct OwnerShared ServicesPI PlanningTeam BacklogPI ObjectivesPI ObjectivesBusiness OwnersProduct ManagementSystem ArchitectRelease Train EngineerAgile Release TrainCustomer CentricityRelease on DemandProducts and SolutionsSystem DemoFeatures and CapabilitiesEnablerFeatures and CapabilitiesFeatures and CapabilitiesInspect and AdaptPI PlanningIP IterationStoryEnablerIterationsPlanning Interval (PI)StoryContinuous Delivery PipelineArchitectural RunwaySAFe ScrumSAFe Team KanbanDevOpsBuilt-in Quality

The Agile Release Train (ART)

When a product or solution is too large for a single Agile Team to deliver, an Agile Release Train (ART) effectively creates alignment across multiple teams and a common way of working, as shown in Figure 1. This approach helps Agile Teams work together more smoothly and ensures that the value they are developing is ready for use at the same time. Agile Teams can deliver value to the market more efficiently and with better quality, surpassing what the enterprise could do with a less organized approach. ARTs are generally made up of 50 -125 people. They are cross-functional and have all the capabilities needed to define, build, validate, release, and, where applicable, operate one or more products or solutions.

ARTs include the following key roles:

  • Product Management – responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle.
  • System Architect – an individual or small cross-discipline team that defines the overall architecture of the system, helps identify Nonfunctional Requirements (NFRs), determines the significant elements and subsystems, and helps design the interfaces and collaborations among them.
  • Release Train Engineer (RTE) – a servant leader and the chief Scrum Master/Team Coach for the train. The RTE facilitates optimizing the flow of value by ensuring the ART events and artifacts function correctly, including the ART Kanban, Inspect & Adapt (I&A) workshop, ART Sync, and PI Planning.
  • Business Owners – a small group of stakeholders with the business and technical responsibility for fitness for use, governance, and return on investment (ROI) for a product or solution developed by an ART. They are primary stakeholders in the ART and actively participate in ART events.

ART Events

The heartbeat of the ART is the Planning Intervals (PIs), which represent fixed timeboxes during which the Agile Release Train delivers continuous value to its customers. The PI starts with PI Planning, a critical cadence-based event that brings all teams on the ART together to align to a shared mission and create a plan for delivering a set of committed PI Objectives.

Throughout the PI, System Demos showcase an integrated view of new features from each iteration, allowing ART stakeholders to assess progress. The Inspect & Adapt (I&A) event at the end of the PI enables teams to evaluate the current solution, reflect on their processes, and identify areas for improvement through a structured problem-solving workshop. Additionally, regular ART Sync, Coach Sync, and PO Sync events streamline communication and coordination across the ART. Additionally, the Innovation and Planning (IP) Iteration allows teams time for exploration, innovation, and dedicated planning. This time can be used for both informal and formal learning opportunities, fostering a culture of continuous growth and improvement.

Agile Teams

Agile Teams are cross-functional groups of ten or fewer individuals who can define, build, test, and deploy an increment of value in a short time box. To facilitate their work, most SAFe teams adopt SAFe Scrum, a lightweight process designed for Agile Teams to deliver value continuously. Likewise, SAFe Team Kanban—also a Lean-Agile method—helps teams visualize their workflows, establish work-in-process (WIP) limits, and measure throughput. Both approaches emphasize the importance of delivering value continuously while encouraging ongoing process improvement.

Each Agile Team includes the following roles:

  • Scrum Master/Team Coach (SM/TC) – a servant leader and Agile Team coach who helps the team remove impediments, facilitates team events and fosters an environment for high-performing teams.
  • Product Owner (PO) – the content authority for the team backlog is responsible for defining stories and prioritizing the backlog.

Technical Agility Practices

The ART builds or shares a Continuous Delivery Pipeline (CDP), allowing Agile Teams to deliver new functionality to users as needed. In some instances, ‘continuous’ may mean daily or even multiple releases per day. In others, this may mean weekly or monthly releases to satisfy market demands and business goals. To support this continuous delivery of value, the ART builds out an architectural runway consisting of the existing code, components, and technical infrastructure needed to implement near-term features with minimal redesign and delay.

To further enhance collaboration and efficiency, a DevOps mindset promotes a culture of communication, integration, and automation among all stakeholders involved in planning, developing, testing, deploying, releasing, and maintaining a system. Additionally, built-in quality is a critical element of scaling agility across multiple teams. This approach describes a set of practices applied to ensure that Agile Teams' outputs consistently meet appropriate quality standards throughout the entire process of creating customer value.

Competencies of the Team and Technical Agility Discipline

Each competency below describes a set of knowledge, skills, and techniques required to achieve mastery in a team and technical agility area. They provide the necessary information, learning resources, and practical application guidance needed to support success. Together, the competencies represent current SAFe guidance for this discipline. However, over time, as new ways of working emerge, the competencies themselves will evolve.

Selecting the competencies to focus on at a particular time will depend on organizational context, individual experience and knowledge, and the current opportunities or gaps of each product. Click on the competency below that you wish to explore.

NOTE: To accelerate value delivery, the competencies of each SAFe discipline will be released in small batches. All those accessible as a ‘blue box’ are currently available, with the remaining ‘greyed out’ competencies to be released incrementally.

Business Problem: Our teams are applying agile team practices, but we are slow to deliver and have low employee engagement.

Business Problem: We have technical software delivery bottlenecks and frequent post-release defects with high maintenance costs.

Business Problem: We are not adapting to changing customer and market needs across our operational departments.

Business Problem: We have no clear visibility into our end-to-end delivery processes that are slow, error-prone, and inefficient.

Business Problem: Our architecture is defined up front, often with minimal collaboration, making it difficult to respond to emerging requirements.

Business Problem: Our marketing efforts struggle to keep pace with emerging requirements and changing priorities, leading to less customer impact.

Business Problem: Our software and hardware teams find it difficult to collaborate because their ways of working are so different.

Business Problem: We have difficulty managing and prioritizing work across teams, inefficient collaboration, and slow value delivery.

Business Problem: We have ambiguous requirements and specifications that cause rework and delay.