Nothing beats an Agile Team.
In SAFe, Agile teams are cross-functional groups of 5-11 individuals who define, build, test, and deliver an increment of value in a short time box.
Because communication quality diminishes as team size increases, Agile enterprises tend to prefer collections of smaller teams. For example, it’s generally better to have two teams of five people than one team of ten.
Solution delivery requires broad and diverse skills. Technical teams define, build, test, and-where applicable-deploy, some element of Solution value. Business teams collaborate with them to provide a range of support that includes:
- Guardrails and other business parameters
- Contracts and suppliers
- End-user training
- Legal guidance
- Security and compliance expertise
- Fitness for use
- Solution knowledge
Both types of teams strive for fast learning by performing work in small batches, assessing the results, and adjusting accordingly. All SAFe Agile teams include two key roles, the Scrum Master and Product Owner.
No train can exist without Agile teams; they power the Agile Release Train (ART) and ultimately the entire enterprise. ARTs are responsible for delivering larger solution value. All teams on the train collaborate with other teams, contribute to its Vision and Roadmap, and participating in ART events. In addition, they are largely responsible for building the Continuous Delivery Pipeline and DevOps capabilities.
By building and supporting the solutions that deliver value to their customers, Agile teams fuel the enterprise. As described in SAFe’s Team and Technical Agility competency article, the Agile movement  represented a major turning point in how software and systems were developed. It produced a cohesive set of values, principles, and practices that sparked the creation of high-performing teams. In SAFe, Agile teams are the building blocks for creating and delivering value. Without effective Agile teams, composed of empowered and motivated individuals, organizations cannot achieve the broader business benefits of Lean-Agile development.
These teams are self-organizing and self-managing, accountable to deliver results that meet the needs and expectations of their customers and stakeholders. They are also accountable to each other and to other teams for delivering quality work on time.
By moving work to the teams and trains, instead of bringing people to the work, Enterprises create Value Streams and can largely eliminate the ‘project model’ of working (see Lean Budgets). They create long-lived teams and teams of teams, dedicated to relentlessly improving their ability to deliver solutions. This is how SAFe differs from the traditional approach in which managers direct individuals to activities. SAFe teams—not their managers—determine for themselves what features and components they can implement in an iteration and how to implement them. Lean-Agile Leaders provide the vision, leadership, and autonomy necessary to foster and promote high-performing teams. As a result, assigning work to individual team members is no longer required as teams are mostly self-reliant. This enables decentralized decision-making all the way to the level of the individual contributor. The primary responsibility of Lean-Agile Leaders then is to coach and mentor Agile teams.
Teamness and High-Performing Teams
Great teams require more than talented individuals. Team composition and dynamics play a significant role. In fact, who is on a team has less impact on team performance than how the team works together . High-performing teams share many common ‘teamness’ characteristics:
- A safe environment for taking risks without fear of embarrassment or punishment
- Alignment on a shared vision with clear goals and purpose
- Diversity of knowledge and skills to make quick, effective decisions independently
- The mutual trust that allows for healthy conflict
- Accountability to each other and the organization by reliably completing quality work and meeting commitments
- Understanding of their work’s broader impact on the organization
- Fun with their work and with each other
SAFe’s Organizational Agility competency provides more information on how Lean-thinking people and Agile teams create better business outcomes.
Agile Team are Cross-Functional
Although organizational hierarchies provide time-tested structures, practices, and policies, they often slow the flow of value delivery. SAFe Principle #10, Organize Around Value, describes how value flows poorly across organizational silos and hierarchies. Instead, Value Streams organize workers to provide the speed and innovation that Business Agility requires.
By working in value streams, Agile teams span those organizational silos. Agile teams are composed of members from across the organization who are dedicated to their team full-time. This eliminates the hand-off and delays that pushing value through silos causes. Each Agile team has all the skills necessary to develop increments of value in a short timebox (Figure 1). They can:
- Define – Independently elaborate and design features and stories to accomplish their mission
- Build – Contain all skills necessary to create the artifacts to meet their mission
- Test – Ensure an artifact’s quality and performance
- Deliver – Validate that results address the intended business need
Agile teams have two specialty roles. The Product Owner defines Stories (along with other team members) and prioritizes the team backlog to streamline the execution of program priorities. At the same time, they also maintain the conceptual and technical integrity of the Features or components the team is responsible for. The Scrum Master is a servant leader and coach for the team. This role instills the agreed-to Agile process, helps remove impediments to progress, and fosters an environment for high performance, continuous flow, and relentless improvement.
SAFe Teams Typically Blend Agile Methods
SAFe teams use Agile practices of choice based primarily on Scrum, Kanban, and Extreme Programming (XP) to improve their performance. To ensure they are solving the right problem, teams apply Design Thinking. Teams apply Built-In Quality practices to drive disciplined content creation and quality. Collective ownership, pair work, standards, test-first, and Continuous Integration help keep things Lean by embedding quality and operating efficiency directly into the process.
However, since 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 choose Kanban as their primary 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 (e.g., support teams).
Responsibilities vary based on team type. Technology-focused teams, including software and hardware, build technical solutions. Business-focused teams create other work products–marketing campaigns, contracts, and customer resolution. Teams typically fulfill the following responsibilities.
- Collaborate with the Product Owner to create and refine user stories and acceptance criteria
- Participate in PI Planning and create Iteration plans and Team PI Objectives
- Develop and commit to Team PI Objectives and iteration goals
- Estimate the size and complexity of their work
- Use pairing and other practices for frequent review
- Determine the technical design in their area of concern, within the architectural guidelines
- Conduct research, design, prototype, and other exploration activities
- Implement and integrate changes in small batches
- Create and test the work products defined by their features
- Test the work products defined by their features
- Deploy the work products to staging and production
- Support operational business solutions
- Support and/or create the automation necessary to build the continuous delivery pipeline
- Continuously improve the team’s process
Software, hardware, IT, operations, and other technology-focused teams:
- Apply test-first practices including Test-Driven Development (TDD) for unit tests and Behavior-Driven Development (BDD) for automated acceptance tests
- Collaborate with architects using Agile Architecture
- Use design and implementation best practices to build high-quality components and solutions
- Manage changes in a shared repository
- Execute acceptance tests and maintain the test cases in a shared repository
Business-focused teams (product marketing, sales, support, training, security, compliance, legal, etc.)
- Collaborate with the technology-centric teams using similar cadence structures and alignment to shared objectives
- Understand and define the business opportunity
- Define the business processes and operational value streams the technical solutions support
- Assure iterative and adaptive practices when creating their unique work products
- Perform work in small batches with fast feedback from customers and stakeholders
- Emphasize many small experiments with fast feedback over a few large, slow initiatives
- Adapt Lean-Agile principles to their unique practices and policies
The last section of this article, Agile Business Teams, provides more guidance on how business-focused teams join the Lean-Agile enterprise.
Collaboration and Culture
Agile teams are motivated by a shared vision and their commitment to delivering value to customers and stakeholders. Each team member is fully dedicated to a single team and works intensely to support its goals. 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. Using regular feedback loops that are built into the learning cycle, collaboration improves continuously. Each tangible delivery of value encourages trust, reduces uncertainty and risk, and builds confidence.
Constant communication and collaboration, along with fast and empowered decision-making, permits teams to meet their responsibilities. Organizations strive to collocate teams, which can be challenging in large enterprises. For distributed team members working offsite, workspace infrastructure and technology exists to enable communication and collaboration. (See Organizational Agility and Agile Workspaces articles for more information.) Standard team meetings depend somewhat on the method of choice, but they typically include a Daily Stand-up, Iteration Planning, Iteration Review, backlog refinement, and Iteration Retrospective.
Agile Teams Are on the Train
In SAFe, Agile teams building and evolving the solution are on the train and operate as a high performing team-of-teams. They power the ART by collaborating to build increasingly valuable increments of working solutions. A common framework governs and guides the train. They plan, demo, and learn together, as illustrated in Figure 3. This alignment enables teams to more independently explore, integrate, deploy, and release value.
All teams attend PI Planning, where they mutually plan and commit to a set of PI objectives. Working towards a shared vision and roadmap, 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, 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.
Delivering complex, high-quality solutions requires 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 of other teams.
Teams apply Built-In Quality practices and engage in continuous exploration, continuous integration, and continuous deployment. This takes place within the team and across the train—working toward an aggregated System Demo to end each iteration.
To address today’s uncertainty and opportunity, SAFe’s Continuous Learning Culture (CLC) challenges organizations to create a culture of fast and effective learning at all levels. Teams and individuals are the heart of the Learning Organization (a CLC dimension) that drives innovation for the enterprise. SAFe fosters Innovative People (another CLC dimension) through many practices including time and space for innovation, experimenting and feedback, and ‘innovation riptides’.
All SAFe teams engage in relentless improvement (see pillar 4 in the Lean-Agile Mindset article and the third dimension in CLC for more information). 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 next PI planning sessions. The teams and the ART progress forward one iteration and PI at a time. Learning is not limited to retrospectives. It happens continuously and is also facilitated by Communities of Practice (CoPs), formed to help individuals and teams advance their functional and cross-functional skills.
Explore, Integrate, Deploy, and Release Independently
Planning, demoing, and learning together creates the alignment that enables teams to independently and reliably deliver value. Agile teams drive value through the entire continuous delivery pipeline. Collaborating with product management around continuous exploration, they continuously integrate, and they continuously deploy their work to staging and (ideally) production environments. While Agile teams strive to independently deploy and release their parts of solutions, some technical, regulatory, and other hurdles may hinder them. In those situations, teams coordinate and align their deployment and release to production.
Agile teams help validate feature hypotheses by deploying to production early and frequently. They design their systems in ways that permit decoupling the solution from the release, enabling the ability to release on demand.
Agile Business Teams
As businesses expand agility across the organization, teams outside core development need guidance on how their skills and practices apply to this new way of working. Their needs may include business and technology leadership, marketing, operations, support, finance, legal, security, compliance, first-article production, and any other functions that are necessary for delivering and sustaining the company’s business solutions. A ‘3 step maturity cycle’ helps them form, advance their processes, and climb on board with the rest of the organization (Figure 4).
Step 1 – Be Agile
First, the teams adopt and master the basic Agile mindset and practices. Although it wasn’t written for them, the Agile Manifesto’s value system and many of the principles apply to their work. It’s the baseline for their interaction with other agile teams. This creates a universal value system and a shared understanding of what Agile is and means. But it goes beyond that. The SAFe House of Lean and the SAFe Lean-Agile principles are equally relevant, and in some cases even more so, ensuring the right mindset for the teams and their leaders.
Teams need to master basic Agile practices, which include:
- Implementing the specialty roles of Scrum Master and Product Owner
- Events like daily standups, planning, demos, and retros,
- Understanding flow and the Kanban practices necessary to enhance team velocity
Some teams will be more comfortable with Scrum; others might find Kanban more effective; while others will blend concepts and practices from both.
Step 2 – Join the Value Stream
Step 1 is a great start to help business teams become Agile, in both the execution and mindset. However, as teams optimize and improve their team-level efficiencies locally, the larger, end-to-end system may suffer.
To address that, most Agile teams should be ‘on the train.’ How that works in practice depends on the scope and the nature of the work the teams do. Teams like product marketing may be directly embedded in ARTs, as whole teams or inside other teams. In other cases, the marketing functions, for example, may operate as a separate train and deliver shared services via coordinated backlogs to the other trains. But the common view of work, a common taxonomy, and shared cadence and synchronization points help the organization and its value stream deliver quickly and predictably with better quality.
Even ‘system integration’ takes a new meaning when new innovations necessitate new policies and procedures around licensing, privacy, security, etc. that become embedded in code, legal documents, operational workflows, and/or other artifacts—all orchestrated by the trains themselves.
Step 3 – Specialize principles and practices
Steps one and two will propel the enterprise further on its way to true Business Agility. However, a final step remains. Over time, it becomes increasingly important that the business teams evolve their own specialization of Lean and Agile principles and practices, as well as implementing what Built-in quality means in their context. In this way, they ‘make Agile their own’. Agile marketing is a good example. Since it is so tightly coupled to Agile development, many publish, consult, and opine on that topic. Further, ‘Agile HR’ is another critical and developing domain for the Agile business.
Many business functions have processes that were established in a pre-Agile era that often conflict with small batches, fast flow, and adjusting. By being more closely connected with the development organization, they evolve these processes and find ways to integrate them into the teams’ and ARTs’ flow of value delivery and better serve the entire organization.
1] Manifesto for Agile Software Development. http://agilemanifesto.org/. Guide: Understand team effectiveness https://rework.withgoogle.com/print/guides/5721312655835136/  Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.  Lencioni, Patrick. The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass, 2002.  McChrystal, Stanley (Retired General) et al. Team of Teams: New Rules of Engagement for a Complex World. Penguin Publishing Group, London, England, 2015  Marquet, David. Turn the Ship Around. Penguin Group. Kindle Edition.
Last update: 20 January 2019