Scaling Agile Teams

We’ve been working with organizations for over 15 years and despite numerous existing frameworks and models, we’ve learned that there is no silver bullet when it comes to scaling Agile teams. Every context is different and complex. However, we believe that by applying Agile principles and some good practices, any organization can create a framework or model for scaling Agile teams: one that is best adapted to its respective environment and can grow organically. In this guide, we’ll describe a few best practices for scaling Agile teams.

Need help scaling? Join our upcoming Webinar: Implementing Agility at Scale, or check out our new training offering below.

Certified Agile Scaling Practitioner 1 (CASP 1)

€1,395.00 (excl. VAT)

Shop now

What is “Scaling”? 

When we speak of “scaling”, we refer to any situation where more than one team is asked to work together to build a product or service to deliver value to the customer faster. With several teams involved, we face new challenges like the need for increased synchronization and improved communication. The following sections provide some good practices that allow us to address those challenges. In the following description, the assumption is that individual teams are working together using the Scrum framework including all of its roles, events, and artifacts.

Scaling Scrum Teams

What are Scrum Teams?

According to the Scrum Guide, “The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”

The guide goes on to describe the characteristics of such a team: “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how”.

The Scrum Guide further recognizes the challenge of scaling teams. “The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people”, it says. “In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

These “multiple cohesive Scrum teams” are the key to scaling. When you have multiple teams focused on the same product, their cohesiveness is reflected by the fact that they are small, cross-functional, and self-managing.’

Multiple Teams with Shared Artifacts

When multiple Scrum teams work on the same product, they should share the same Product Goal, Product Backlog, and Product Owner. Additionally, they must mutually define and comply with the same Definition of Done, since each team’s work needs to meet the same quality standards.

Product Development with Multiple Teams

When working with multiple teams, a Product Owner usually has more to do than one person can handle. In this case, it may be a good idea to establish a Product Owner Team which consists of a few people who share the responsibility of managing the Product Backlog.

Another option is to nominate a Chief Product Owner who coordinates the interaction and collaboration of several Product Owners who work closely with different teams. In this case, the Chief Product Owner is responsible and accountable for maximizing the value of the product and ordering Product Backlog Items accordingly. They delegate some of their responsibility to other Product Owners.

The following paragraphs will explore practices and tools that help organize, coordinate, and synchronize multiple Scrum Teams.

Cross-Team Collaboration

An organization with multiple teams working on one or more products or services needs to ensure value is being delivered across all teams. Since the work of one team might impact other teams, dependencies need to be identified and managed. 

Visualizing the Workflow

A Coordination Board is a good way of visualizing work across multiple teams, as shown in the graphic below. 

The Coordination Board promotes cross-team collaboration in that it gives transparency to the work and a sense of accountability for the contributing teams and individuals. It also helps prioritize feature delivery, identify and remove dependencies and blockers, and coordinate activities between the teams. With the Coordination Board, we zoom out from the team level and focus on cross-team collaboration. Feedback loops between the Coordination Board and the teams’ boards ensure alignment among teams.

The Coordination Board Process

The Coordination Board represents an end-to-end workflow and lists any activities necessary to deliver value. This ensures that the right teams work on the right things at the right time. It visualizes the steps necessary for an item from idea to delivery to customers and beyond. Typical columns of the Coordination Board are qualification, planning, execution, and monitoring.

Each column represents one phase in the lifecycle of an item. Explicit policies should define the entry criteria for each column as well as the practices and interactions performed in each step. Visual clues can be used to convey additional information and speed up decision-making.

Limiting Work in Progress creates focus and ensures fast problem-solving. By using flow and business metrics, the progress of items on the Coordination Board can be measured and improved.

Product Owners can use the Coordination Board to formulate the next Sprint Goal or define a cluster of features for the next release. The results of each Sprint are then fed back into the Coordination Board.

Participants

Representatives from all teams and relevant stakeholders must meet regularly in front of the Coordination Board to share updates and manage dependencies and blockers. This includes Product Owners, stakeholders, and representatives of all Scrum Teams, depending on the context.

Cross-Team Sprint Planning

When several Scrum Teams collaborate in order to achieve a shared Product Goal, it is crucial for all of them to align themselves with a shared Sprint Goal which would bring them one step closer to the Product Goal. However, creating a detailed plan for getting selected Product Backlog Items done during the Sprint is best still conducted on a team level during the Scrum Teams’ respective Sprint Planning (along the lines of the Scrum Guide).

So how do we marry these two seemingly divergent ideas? We advise that when working with multiple teams, you should split Sprint Planning into different parts. This enables Scrum Teams to converge when overall alignment or planning is necessary and to diverge to work on a team level whenever possible. This allows every Scrum Team to hold their own Sprint Planning (parts 1 and 2), ensuring that they align with other teams on the shared Sprint Goal (part 0) and on which items will be tackled by each team (part 3).

Sprint Planning Phase 1: Alignment 

Purpose

In Cross-Team Sprint Planning 0, Scrum Teams align in order to ensure that they are all working towards the same Sprint Goal. Without alignment, teams may waste time on Product Backlog Items not part of the Sprint Goal or fall out of sync.

Therefore, the Cross-Team Sprint Planning 0 is a joint meeting attended by representatives from all Scrum Teams, allowing them to collaboratively define why the Sprint is valuable, which Sprint Goal to work towards, and which Product Backlog Items each Scrum Team could pull in order to achieve the Sprint Goal.

Process

Product Owners propose how the product could increase its value and utility in the upcoming Sprint. Representatives of the Scrum Teams then collaboratively define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. Once the Sprint Goal is finalized, Product Owners share the top priority Product Backlog Items with the teams and final questions are clarified. The teams then pull the items that each Scrum Team wants to take to their respective Sprint Planning (Sprint Planning 1 and 2) and they collaboratively identify opportunities to work together in the upcoming Sprint.

Cross-Team Sprint Planning 0 needs to be completed before moving on to Sprint Planning 1 and 2, where each Scrum Team builds their Sprint Backlog and agrees on how the chosen work will get done.

Participants

Product Owners and representatives (e.g. Developers) of each Scrum Team.

Sprint Planning Phase 2: Teams Separate for Sprint Planning

Teams plan their own Sprints individually and internally after ensuring they are aligned with the overall goal (along the lines of the Scrum Guide).

Cross-Team Sprint Planning Phase 3: Alignment 

Purpose

At this point, Scrum Teams are aware of the Sprint Goal, have created their Sprint Backlog in Sprint Planning 1 and 2 and might have a rough idea of the Product Backlog Items that other teams have pulled. However, they are not aware of what other Scrum Teams have committed to.

Cross-Team Sprint Planning 3 is the opportunity for all teams to get a shared understanding of the items each Scrum Team has committed to work on in the upcoming Sprint. It is also an opportunity to commit to working together on particular topics when needed and to clarify how to handle any dependencies.

Process

Once each Scrum Team has held their respective Sprint Planning, representatives from each team come together in Cross-Team Sprint Planning 3 to share their Sprint Backlogs as an outcome of their Sprint Planning 1 and 2 by communicating the commitments of each Scrum Team.

They can also align and commit to collaboration for closely related items and conclude by starting the Sprint.

Participants

Product Owners and representatives of all Scrum Teams, depending on the context.

Mid-Sprint Collaboration

Once a Sprint has started, there are several opportunities for the team members to collaborate across teams: 

• To resolve dependencies and remove blockers in a Scrum of Scrums
• To collaborate with stakeholders on Product Backlog Refinement
• To share knowledge and improve skills in Communities of Practice

Scrum of Scrums

When multiple teams are expected to collaborate and build something together, there will always be some challenges. These might include poor communication, misaligned priorities, or missing cohesion. Therefore, working at scale requires more frequent synchronization between teams and increased communication. This is where the Scrum of Scrums comes in.

What is a Scrum of Scrums?

The Scrum of Scrums is a meeting between teams that enables team members to connect better through frequent exchanges to be aligned on tasks and priorities. It is a vital tool to help manage or resolve dependencies between teams, such as when one team’s work may be impacted by another’s.

How to run the Scrum of Scrums

Each Daily Scrum within a Scrum Team ends by designating one member as an “ambassador” to participate in a meeting with ambassadors from other teams, called the Scrum of Scrums. The Scrum of Scrums doesn’t have to be daily, it could also be held once or twice per week or Sprint, depending on the teams’ need for synchronization.

The Scrum of Scrums proceeds as a normal daily meeting, with ambassadors reporting completions, next steps, and impediments on behalf of their team. Resolution of impediments is expected to focus on the challenges of coordination between teams; solutions may entail agreeing to interfacing between teams, negotiating responsibility, defining boundaries, etc.

The Scrum of Scrum will track these items via its own backlog, where each item contributes to improving between-team coordination.

Participants

Depending on the context, ambassadors may be technical contributors and/or each team’s Scrum Master.

Product Backlog Refinement

Purpose

Without a shared understanding among all teams working on the same product or service, the organization risks wasting effort by working on the wrong things or missing more valuable and important ones. 

Product Backlog Refinement improves the efficiency of the Sprint Planning meetings because it allows teams to clarify open questions and leverages the benefits of collaboration in prioritizing and capturing Product Backlog Items directly with stakeholders and the development team.

Process

Product Backlog Items are refined until they are ready for selection in a Sprint Planning event. Product Backlog refinement refers to the act of breaking down and further defining items into smaller, more precise items of value. Product Owners, Developers, and stakeholders collaborate to add detail, estimates, and an order to Product Backlog Items.

An overall Product Backlog Refinement with two or more Scrum Teams involved can be useful whenever it is necessary for shared understanding, to use alignment opportunities for closely related items, or when broader input or knowledge sharing is required.

Participants

Product Owners, Stakeholders, and representatives of all Scrum Teams, depending on the context.

Communities of Practice

Purpose

A Community of Practice’s goal is to share knowledge, improve skills, and advance the state of craft. Communities of Practice are intended to support individuals with specific professional needs by allowing space and time to share practice and knowledge. It is very gratifying to learn and share with a group of peers, who may have similar solutions to common problems or have found something else to work better for them.

Process

Participation in self-organizing Communities of Practice is voluntary. Membership includes only people who are practitioners of the same craft or skill. Management support is helpful; management participation or facilitation is generally not.

A CoP typically has periodic meetings. Meetings may have a default agenda, with specific topics depending on the type of activity taking place. Common activities include: sharing good practices and patterns, setting guidelines and standards for their specialty (e.g. UI standards), helping each other overcome challenges, establishing and maintaining knowledge repositories, doing research on emerging technology, or developing strategies for long-term improvement across the organization.

Participants

Agile organizations often form separate communities for Product Owners, Scrum Masters, testers, UI/UX specialists, analysts, and developers. Beyond that, every group of individuals who share professional needs can gather in a Community of Practice in order to share practice and knowledge. Members come from teams and departments across the entire organization.

Cross-Team Sprint Review

Purpose

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. Scrum Teams present the main results of their work to key stakeholders and progress toward the Product Goal is discussed.

Cross-Team Sprint Reviews can be valuable when more than one team works on the same product or service and they benefit from greater visibility or if the business stakeholders are the same group of people for all Scrum Teams.

Process

Similarly to Sprint Planning, the Sprint Review can be divided into different parts when working with multiple teams: one Sprint Review per Scrum Team and one Cross-Team Sprint Review for all teams working on the same Sprint Goal.

During each Scrum Team’s Sprint Review (along the lines of the Scrum Guide), Product Backlog Items that are valuable for a larger audience of stakeholders are identified. Representatives from each Scrum Team then join the Cross-Team Sprint Review together.

During the event, Scrum Teams and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, participants collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

The Cross-Team Sprint Review is a working session and Scrum Teams should avoid limiting it to a presentation.

Participants

Product Owners and representatives of all Scrum Teams, depending on the context.

Cross-Team Sprint Retrospective

Purpose

The Sprint Retrospective is time set aside for a team to reflect on past events and behaviors and plan ways to improve the quality and effectiveness of its work.

Process

Similarly to the Sprint Review, the Sprint Retrospective is divided into different parts: one Sprint Retrospective per Scrum Team and one Cross-Team Sprint Retrospective for all teams working on the same Sprint Goal.

Once each Scrum Team has held its own Sprint Retrospective (along the lines of the Scrum Guide), representatives from each Scrum Team hold a Cross-Team Retrospective together that enables them to identify and address issues that cannot be resolved at the team level or that are valuable for improving collaboration and communication across teams.

The most impactful improvements are addressed as soon as possible. They may be added to the Sprint Backlog for the next Sprint and usually 10% of the Sprint capacity is allocated to address those improvements.

Participants

Representatives of all Scrum Teams, depending on the context.

Conclusion

The Scaling Framework described above is built on top and around a functioning Scrum Framework at team level. However, we have seen these principles and good practices work with established Kanban teams or a combination of Scrum and Kanban teams as well. 

We want to emphasize that the good practices for scaling agile teams described above are not to be seen as a prescriptive framework where you must simply follow all the rules to make it work and succeed.

On the contrary, we encourage you to apply the agile principles enriched with some good practices in order to create your own framework or model for scaling agile teams, one that can be most successfully adapted to your organization’s respective environment and that can grow organically.

Are you in the process of Scaling?

Scrum Alliance has launched a new certification to help you in this process. Certified Agile Skills – Scaling 1 (CAS-S1) addresses the most common challenges when it comes to scaling, including: 

• What is Scaling and Why is it Necessary?
• Approaches to Scaling (Principles-led, Practice-led, Pattern-led)
• Principles of Organic Scaling
• Introduction to Complexity and System Thinking
• Value Delivery and Unnecessary Synchronizations
• Organizational Culture and Decentralized Control
• Scaling Patterns
• Change Management in Scaling
• The Role of Agile Coaches in Scaling
• Scaling Case Study Deconstruction