Nothing beats an Agile Team.

SAFe mantra

Agile Teams

Find a Course:

The SAFe Agile Team is a cross-functional group of 5 to 11 people who have the responsibility to define, build, test, and where applicable deploy, some element of Solution value—all in a short Iteration timebox. Specifically, the SAFe Agile Team incorporates the Dev Team, Scrum Master, and Product Owner roles.

As described in SAFe’s Team and Technical Agility competency, Agile Teams power the Agile Release Train (ART) and ultimately the entire enterprise.  ARTs are responsible for delivering larger solution value. No train can exist without its teams. And all teams are on a train, contributing to its Vision and Roadmap, collaborating with other teams, and participating in ART events. In addition, they are largely responsible for building the Continuous Delivery Pipeline and ART DevOps capabilities.

The teams and the train are inseparable; the whole is greater than the sum of its parts.


The Agile movement [1] represented a major turning point in the way software and systems were developed. SAFe builds on this change by empowering Agile Teams as the building blocks for creating and delivering value. Without effective Agile Teams, composed of empowered and motivated individuals, organizations cannot achieve the larger business benefits of Lean-Agile development.

Together, an Agile Team has all the skills necessary to develop increments of value in a short timebox:

  • Define – Elaborate and design features and components
  • Build – Implement features and components
  • Test – Run test cases to validate features or components
  • Deploy – Move features to ‘staging’ and ‘production’ environments

While operating within the context of the ART, teams are empowered, self-organizing, and self-managing. They’re accountable to deliver results that meet the Customer’s needs and expectations. Teams develop software, hardware, firmware, or some combination. But mostly, a team represents a collaboration of the cross-functional disciplines necessary to deliver Features or components.

By moving work to the teams and trains, instead of bringing people to the work, Enterprises can largely eliminate the ‘project model’ of working (see Lean Budgets) and instead create teams, and teams of teams, that are long-lived and dedicated to relentlessly improving their ability to deliver solutions. This is what makes SAFe different from the traditional approach, in which managers direct individuals to activities. SAFe teams—not their managers—determine what features and components they can build in an iteration and how to build them. Lean-Agile Leaders provide the vision, leadership, and autonomy necessary to foster and promote high-performing teams. Assigning work to individual team members is no longer required as teams are largely self-organizing and self-managing. This enables decentralized decision-making all the way to the level of the individual contributor. The primary responsibility of Lean-Agile Leaders then becomes the coaching and mentoring of Agile Teams.

SAFe Teams Typically Blend Agile Methods

SAFe teams use Agile practices of choice, based primarily on Scrum, Kanban, and Extreme Programming (XP). Most SAFe teams apply Scrum with XP (see SAFe ScrumXP) as the basic framework. The Product Owner manages the Team Backlog. The Scrum Master facilitates the team toward its delivery objectives and helps build a high-performing and self-managing group.

Teams apply Lean UX feature development and Built-In Quality practices to drive disciplined development and quality. These practices—including collective ownership, pair work, coding standards, test-first, and Continuous Integration—help to keep things Lean by embedding quality and operating efficiency directly into the process. Agile Architecture completes the picture for quality solution development.

However, as SAFe is a flow-based system, most teams also apply Kanban to visualize their work, establish Work in Process (WIP) limits, and use Cumulative Flow Diagrams (CFDs) to illustrate bottlenecks and key opportunities for improving throughput. Some teams—especially maintenance teams and System Teams—often apply Kanban as their base practice. This is because the planning and commitment elements of Scrum may not apply as efficiently for workloads that are activity and demand-based, and where priorities change more frequently.


SAFe facilitates moving away from the traditional, phase-gated development model, in which user value is delivered at the end of a long life cycle with input from separate functional silos (requirements, design, test, deploy). Instead, Agile Teams perform all of these functions while delivering value at every iteration. Agile Teams are responsible for managing their work and producing value across the full lifecycle from Continuous Exploration to Continuous Integration to Continuous Deployment to Release on Demand. In order to do this, the team:

  • Estimates the size and complexity of the work
  • Determines the technical design in their area of concern, within the architectural guidelines
  • Commits to the work it can accomplish in an iteration or Program Increment (PI) timebox
  • Implements the functionality
  • Tests the functionality
  • Deploys the functionality to staging and production
  • Supports and/or builds the automation necessary to build the continuous delivery pipeline
  • Continuously improves their process

In addition, wherever possible, Agile Teams are structured with the skills and responsibilities to be able to build and manage the continuous delivery pipeline and to release their element (feature, component, subsystem, or product) as independently as possible.

Collaboration and Culture

Agile Teams are motivated by a shared vision and their commitment to delivering value to the customer. Each team member is fully dedicated to a single team and works intensely. Team members continuously and actively engage with other teams to manage dependencies and resolve impediments. Relationships within the team are based on trust, facilitated by a common mission, Iteration Goals, and team PI Objectives. Collaboration is continuously improved using regular feedback loops that are built into the learning cycle. Each tangible delivery of value encourages trust, reduces uncertainty and risk, and builds confidence.

Teams can meet their responsibilities only through constant communication and collaboration, and through fast, effective, and empowered decision-making. If at all possible, teams are collocated to facilitate hourly and daily communication. Standard team meetings depend somewhat on the method of choice, but they typically include a Daily Stand-up, Iteration PlanningIteration Review, backlog refinement, and Iteration Retrospective.

Agile Teams Are on the Train

SAFe Agile Teams do not operate independently; they power the ART by collaborating and building increasingly valuable increments of working solutions. All teams operate within a common framework that governs and guides the train. They plan together, integrate and demo together, deploy and release together, and learn together, as illustrated in Figure 1.

Figure 1. Agile Teams plan together, integrate and demo together, release and deploy together, and learn together

Plan Together

All teams attend PI Planning, where they plan and commit to a set of PI objectives together. They work toward a common vision and roadmap, and they collaborate on ways to achieve the objectives. Clear content authority roles facilitate the planning and execution process. The Product Owner is part of a larger Product Management team. The team’s individual team backlogs are driven in part by the Program Backlog.

In addition, as part of the ART, and in accordance with the Economic Framework, all Agile Teams participate in a common approach to estimating work. This provides a meaningful way to help decision-making authorities guide the course of action based on economics.

Integrate and Demo Together

Delivering complex, high-quality systems require intense inter-team cooperation and collaboration. To support this, teams work on a common ART cadence and publish and communicate iteration goals at the beginning of each iteration. They also update other teams during the ART sync and actively manage dependencies by interacting with team members from other teams.

Of course, the goal is not to simply have the teams ‘sprint’ toward the goal. Rather, the objective is to have the system sprinting forward in quality-based, measurable increments. To support this, teams apply built-in quality and engage in continuous exploration, continuous integration, and continuous deployment. This takes place inside the team and across the train—while working together toward an aggregated System Demo that occurs at the end of each iteration.

Deploy and Release Together

Agile Teams drive value through the entire continuous delivery pipeline. They collaborate with product management around continuous exploration, they continuously integrate, and they continuously deploy their work to staging and production environments.

Agile Teams help validate feature hypotheses by deploying early and frequently to production. They design their systems in ways that enable decoupling the solution from the release and enable the ability to release on demand.

Learn Together

All SAFe teams engage in relentless improvement (see pillar 4 in the Lean-Agile Mindset article). In addition to iteration retrospectives and ad hoc process improvements, teams also participate in ART Inspect and Adapt (I&A) meetings, where they identify and prioritize improvement backlog items that are incorporated into the following PI planning sessions. This closes the loop, as the teams and the ART progress forward one iteration and PI at a time. Of course, learning is not limited to retrospectives. Learning happens continuously and is also facilitated by Communities of Practice (CoPs), formed to help individuals and teams advance their functional and cross-functional skills.

Learn More

[1] Manifesto for Agile Software Development.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

[3] Lencioni, Patrick. The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass, 2002.


Last update: 9 October 2018