Nothing beats an Agile Team.

—SAFe mantra

Agile Teams

In SAFe, an Agile team is a cross-functional group 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
• Infrastructure
• Contracts and suppliers
• End-user training
• Legal guidance
• Marketing
• 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.

Details

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 [1] 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 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 Stories 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 [2]. 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 Teams are Cross-Functional

Agile teams span functions and are composed of 5-11 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
• Deploy – Where applicable, deploy increments of value

Agile Teams Contain Two Specialty Roles

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 work 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 facilitates the removal of impediments to progress, and fosters an environment for high performance, continuous flow, and relentless improvement.

Agile Teams Have Well-Defined Responsibilities

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.

All teams:

• 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 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

Additional guidance for applying Agile to specific business and technical domains can be found in the Business and Technology article.

Agile Teams are Organized Around Value

SAFe Principle #10 – Organize around value, guides enterprises to organize people and teams around one goal: the continuous delivery of value to the customer. But to do so, they must consider how best to design their Agile Teams.

In their book, Team Topologies, Mathew Skelton and Manuel Pais, describe four fundamental teams types that enhance and simplify this task of organizing around value, (Figure 3). These team ‘topologies’ provide insights on how to organize solution builders and create a clear model for organizing Agile Teams within SAFe. The four team topologies are described in detail below.

Stream-Aligned Teams

The term ‘stream-aligned’ emphasizes the importance of organizing teams to deliver a continuous ‘stream’ of value within the development value stream that builds, runs, and supports the product or solution. Skelton and Pais define a stream-aligned team as follows:

A stream of work, empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work. [3]

One of the most significant benefits of organizing teams in this way is customer centricity; each team has a direct relationship to the customers they serve. Stream-aligned teams apply design thinking practices to better understand these customer personas —building and supporting their desired features. It stands to reason that most teams in a Lean-Agile enterprise should be stream-aligned.

In SAFe, teams operate within ARTs that fulfill larger development value streams. Rarely can a single stream-aligned team build an entire solution. More commonly, stream-aligned teams support a portion of the development value stream, aligned to one of the following aspects:

• A specific solution or solution subset
• A set of features
• A specific customer persona
• Specific steps in the customer journey
• A specific business domain
• Compliance and regulation requirements
• New product innovation

The determining factor is whether the stream-aligned team has the authority and responsibility to build and deliver customer value with minimal dependencies on other teams. This requires that stream-aligned teams be cross-functional and include all the skills necessary to build and support whatever features and components they need. This also ensures that stream-aligned teams are long-lived, developing knowledge developing efficiencies over extended periods of time.

For each team type, Skelton and Pais define a set of expected behaviors. Within the context of SAFe, we interpret these responsibilities for stream-aligned teams as follows:

• Know your customer – build and maintain direct relationships with customers and develop a deep understanding of the market segments served.
• Develop a steady flow of new features – features describe a customer need and the associated benefits. New features should make up the majority of the work a stream-aligned teams delivers.
• Apply Design Thinking – understand the problem space, explore solution options, validate with customers, and incorporate feedback.
• Apply continuous improvement practices – reserve capacity for improving the processes and tools needed to do the work.
• Build in quality – take responsibility for ensuring all work meets appropriate quality standards throughout development.
• Collaborate – identify and manage collaborations with other teams on the ART and shared services
• Respond to customer needs – react to new feature requests, incidents, and adjust the course of action.
• Support the solution in production – stream-aligned teams take responsibility for supporting their solution elements in production. In other words, “they build it; they run it.”

Complicated-Subsystem Team

While it is a reasonable ambition is to have primarily stream-aligned teams, it’s unlikely that this will be the only team type required. As solutions become bigger and more complex—often including a mix of hardware and software components—they will likely include subsystems. Building and operating some of these subsystems requires specialist knowledge and expertise.

Skelton and Pais acknowledge this by defining the purpose of a complicated subsystem team:

A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the subsystem. [3]

Requiring stream-aligned teams to gain and maintain the requisite skills to the necessary proficiency levels across all potential subsystems would create too much cognitive load. The teams can become overwhelmed by the complexity, unable to focus on a domain they can truly master. Instead, complicated subsystem teams pick up a big portion of that load, taking responsibility for building and maintaining those parts of the system that require deep and ongoing technical expertise.

A complicated subsystem team could build things such as:

• Highly specialized system components, often used across multiple systems
• Safety-critical systems elements, which have a high cost of failure
• Specialty algorithms or business rules that are critical for fitness of use in the domain
• A part of a cyber-physical system (e.g., an engine control module in an autonomous vehicle)

While all solutions can be decomposed into subsystems, not all subsystems require complicated subsystem teams. The level of expertise, complexity and risk should be the only deciding factors for creating complicated subsystem teams.  As a rough guide, a single ART should contain no more than 1-3 complicated subsystem teams.

The responsibilities and behaviors of complicated subsystem teams include:

• Build, maintain, and support the complicated subsystem – recognize and commit to the critical technical elements they build.
• Maintain their level of expertise – continue to advance the knowledge and skills required to work within that subsystem domain.
• Collaborate with stream-aligned teams – ensure the subsystems are developed to meet customer requirements.
• Plan and prioritize effectively – align the subsystem roadmap with the needs of the stream-aligned teams.
• Develop appropriate interfaces – hide the complicated nature of the subsystems behind well-documented, easy to use interfaces.
• Takes responsibility for built-in quality – assure quality, performance, and architectural robustness of the subsystem.

Platform Teams

A technology or computing platform is a set of services that the stream-aligned teams can access, typically via a set of self-service APIs. Much like the complicated subsystem teams, platform teams (and the platforms they maintain) are created to reduce a stream-aligned team’s cognitive load. Moreover, they should be allocated in a way that increases the autonomy of the stream-aligned teams.

Platform teams are defined as follows:

Platform team[s] provide the underlying internal services required by stream-aligned teams to deliver higher-level services or functionalities, thus reducing their cognitive load. [3]

This focus on platform teams as ‘service providers’ heavily influences the way they work. Platforms are treated as ‘products’ developed for their customers, which in this case are the stream-aligned teams that utilize them. Customer Centricity and Design Thinking apply in this context also. Additionally, the services they provide should be well documented, easy to use, fit for purpose, ‘thin,’ and offer reuse opportunities.

Responsibilities and behaviors of platform teams include:

• Collaborate with stream-aligned teams – ensure the platforms are developed in line with customer requirements.
• Build the platform incrementally – build and deploy in increments and secure frequent feedback and validation from customers.
• Focus on usability – provide platforms that are easy to use via self-service capabilities and supporting documentation.
• Commit to support and maintenance – ensure the platform’s sustainability and uptime, and commit to appropriate service-level agreements.
• Lead by example – keep the platforms ‘thin’ and develop them on top of other platforms where applicable.

Enabling Teams

The tools and techniques for solution development are constantly changing, providing organizations with regular opportunities to integrate new practices and technologies. Although this brings many benefits, it also represents challenges to developing the necessary skills and expertise across all the teams. ‘Enabling’ teams are an important construct. They can provide support and guidance to other teams, assisting them in gaining these new skills and getting up to speed with these emerging technologies.

Enabling teams are defined as follows:

Enabling teams … help stream-aligned teams acquire missing capabilities, usually around a specific technical or product management area. [3]

One example of an enabling team in SAFe is the System Team, which assists ART teams with (among other things) building and supporting the continuous delivery pipeline. Some more specialized examples of enabling teams might provide expertise and support in the following areas:

• DevOps implementation
• Automated testing
• Continuous integration and build tooling
• Engineering quality practices
• Security
• Environments and configuration

Enabling teams may also be focused on helping stream-aligned teams the first few times they need to integrate with a specific subsystem or platform. However, enabling teams are not there to fix quality issues caused by stream-aligned teams. Rather, they work with them for short periods, typically for a PI or so, to increase their skills and embed the required capabilities. Depending on their charter, enabling teams may be persistent and move to support another team, ART, or part of the organization. Or, they may be created for a specific purpose and then be decommissioned and return to their regular work.

Responsibilities and behaviors of enabling teams include:

• Innovative – identify opportunities for improvement, including adopting new technologies and practices.
• Collaborate proactively – identify the teams they need to work with, understand their specific requirements, and check progress regularly.
• Communicate regularly – keep the teams and the wider organization abreast of new technologies and emerging best practices.
• Promote a continuous learning culture – within their own team, the teams they are working with currently, and across the wider organization.

Agile 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).

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 4.  This alignment enables teams to more independently explore, integrate, deploy, and release value.

Plan Together

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.

Demo Together

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.

Learn Together

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) events, 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.

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, although this is not always practical. For distributed team members working offsite, workspace infrastructure and technology exists to enable communication and collaboration. (See the advanced topic article, Working Successfully in Agile with Remote Team Members for additional guidance.) Standard team events depend somewhat on the method of choice, but they typically include a Daily Stand-up, Iteration Planning, Iteration Review, backlog refinement, and Iteration Retrospective.

---

Learn More

[1] Manifesto for Agile Software Development. http://AgileManifesto.org/

[2] Guide: Understand team effectiveness. https://rework.withgoogle.com/print/guides/5721312655835136/

[3] Skelton, Mathew, and Manuel Pais. Team Topologies. IT Revolution Press, 2019.

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

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

[6] McChrystal, Stanley (Retired General), et al. Team of Teams: New Rules of Engagement for a Complex World. Penguin Publishing Group, 2015.

[7] Marquet, David. Turn the Ship Around. Penguin Group, 2013.

 

Last update: 27 September 2021