Agile Team

Nothing beats an Agile Team.

SAFe mantra

Agile Teams Abstract

The Agile movement, as captured in part by the Agile Manifesto (2001), represented a major turning point in the way software and systems development are performed. 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 scale Agile to achieve the larger business benefits of Enterprise Lean-Agile development. The primary responsibility of Lean-Agile Leaders becomes to create and mentor these Agile Teams.

The SAFe Agile Team is a cross-functional group of individuals who have the ability and authority to define, build, and test Solution value—all in a short Iteration timebox. The team includes the individuals necessary to successfully deliver this value, supported by Program Level or Value Stream Level specialists where applicable. This follows the SAFe principle of decentralized decision-making by bringing the authority for local requirements and designs to the teams responsible for doing the actual work.

In SAFe, Agile Teams are not stand-alone units. Instead, they are an integral part of the Agile Release Train (ART), where they collectively have responsibility for delivering larger value. All teams are on a train; no train exists without its teams. Teams operate in the context of the train, adhering to its Vision, collaborating with other teams, and participating in key ART ceremonies. The teams and the train are inseparable; the whole is greater than the sum of its parts.


An Agile Team consists of a small group of dedicated individuals (5 – 9 in Scrum), who together have the skills necessary to define (elaborate and design their component/feature), build (implement their component/feature), and test (run the test cases and validate the component/feature) increments of value in a short timebox. Within the context of the Agile Release Train (ART), teams are empowered, self-organizing, and self-managing and are accountable for delivery of results that meet the Customer’s needs and expectations. These teams develop software, hardware, firmware, or some combination, but most generally the team represents a collaboration of the disciplines necessary to deliver Features.

By moving work to the teams and trains, instead of bringing people to the work, Enterprises help create teams, and teams of teams, that are long lived and dedicated to relentlessly improving their ability to deliver Solutions. In this way, SAFe is different from the traditional approach in which managers direct individuals to activities. SAFe teams—not their managers—determine what and how to build their features and components. Lean-Agile Leaders provide the Vision, leadership, and autonomy necessary to foster and promote high-performing teams. Tasking individual team members with work items is no longer required. This brings the chain of decentralized decision-making all the way to the level of the individual contributor.

Roles and Responsibilities

SAFe facilitates withdrawal from the functional, silo-based, and stage-gated development model, in which user value is delivered at the end of a long life cycle with input from separate functional departments. Agile Teams perform or participate in all of these functions and do so in a way that delivers value in every Iteration:

  • The team is responsible for managing their work
  • The team estimates the size and complexity of the work
  • The team determines the technical design in their area of concern, within the architectural guidelines
  • The team commits to the work they can accomplish in an iteration or Program Increment (PI) timebox
  • The team is responsible for value and builds to continuously improve the quality of their deliverables
  • The team is continuously committed to finding ways to improve

Intense Collaboration

Teams can meet their responsibilities only via constant communication and collaboration and fast, effective, and empowered decision-making. If at all possible, teams are collocated to facilitate hourly, daily, and weekly communication. Standard team meetings depend on the framework of choice but may include a daily stand-up, Iteration Planning and Team Demo, and a retrospective at the end of each iteration. Each team member is fully dedicated to a single team and works intensely during a responsible workweek. Team members continuously and actively engage with other teams to manage dependencies and resolve impediments. Relationships within the team are fundamentally based on trust, and trust is facilitated by a common mission, common Iteration Goals, and team PI Objectives. Collaboration is continuously improved using regular feedback loops that are built into the learning cycle of the teams. Each tangible delivery of value encourages trust, reduces uncertainty and risk, and builds confidence. Agile Teams are motivated by a shared vision and their commitment to deliver value to the Customer.

Teams Have a Choice of Agile Methods

SAFe teams use Agile practices of choice, based primarily on Scrum and Team Kanban. Most SAFe teams apply Scrum as the basic project management and delivery framework. The Scrum Product Owner participates in and supports decentralized decision-making, which is critical to team empowerment. The Scrum Master facilitates the team toward their delivery objectives and helps build a high-performing and self-managing team.

But Scrum is not exclusive. Teams apply User Experience (UX)-inspired engineering 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 keep things Lean by embedding quality and operating efficiency directly in the development process. Agile Architecture helps complete the picture for quality solution development.

However, as SAFe is a flow-based system, most teams also apply Kanban to visualize their work, establish WIP limits, and use Cumulative Flow Diagrams to illustrate bottlenecks and key opportunities for improving throughput. Some teams—especially maintenance teams, DevOps, and System Teams—often apply Kanban as their base practice, as 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.

Agile Teams Are on the Train

SAFe Agile Teams do not operate independently; they power the ART and collaborate on building ever more valuable increments of working solutions. Whether the teams apply Scrum, Kanban, or a blend of both, all teams operate within a common framework that governs and guides the train. They plan together, integrate and demo together, and learn together, as is illustrated in Figure 1.

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

Plan Together

All teams—and wherever possible, all team members—attend PI Planning, where they plan and commit to a set of PI objectives together. They work with 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 content authority team (Kanban teams sometimes have a different name for this role). The team’s individual Team Backlogs are driven in large 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 authorities guide the course of action based on economics. The means to accomplish this vary based on the method chosen, but the result is the same, as is further described in the Scrum and Team Kanban articles.

Integrate and Demo Together

Delivering complex systems of high quality requires intense inter-team cooperation and collaboration. In support of 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, evaluable increments. In support of this, teams apply built-in quality and engage in continuous integration throughout the iteration—both inside the team and across the train—while working together toward an aggregate System Demo that occurs at the end of each iteration.

Learn Together

All SAFe teammates engage in relentless improvement (see Pillar 4 in the Lean-Agile Mindset article). In addition to Team Level retrospectives and ad hoc process enhancements, teams participate in the larger Inspect and Adapt meetings, where they identify and prioritize improvement Stories that are incorporated into the following PI planning sessions. In this way, the “loop is closed” as the teams and the ART progress forward one iteration, and one PI, at a time. And, of course, learning is not relegated exclusively to retrospectives; learning happens continuously in the context of Communities of Practice that have been formed to help individuals and teams advance their functional and cross-functional skills.

Learn More

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

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

[3] Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009.

[4] Manifesto for Agile Software Development.

Last update: 6 April 2016