---

How To Scale The Scrum Framework (Distributed & Large Scrum Projects)? This Might Surprise You!

The Scrum Framework - as described so far - works best for a single Scrum Team in one location. However, in reality, a singular Scrum Team often cannot implement a project entirely, or the team members have to spread over multiple locations.

When one team cannot meet the product’s needs, an organization may consider additional teams. Geographic distribution alone does not require more teams, and adding people can increase coordination costs. In many instances, we have also been observing that those teams are distributed in geographically distant locations or continents.

There are numerous reasons which motivate organizations to distribute their teams across different locations:

• Technical Reasons: Some knowhow to build separate components of the software are not locally available in the headquarters,
• Expertise Reasons: Some capabilities related to the execution of different software engineering activities are not locally available. For instance, test automation, user interface design, or integration of in-house software to the software of other vendors can require experts outside the headquarters,
• Size-related Reasons: The project takes more people on board to deliver it to its clients in a predefined timeline. If this is the case, then the project organization will need more members than it can conceivably fit one single Scrum Team. This may call for multiple cohesive Scrum Teams, rather than expanding a single Scrum Team indefinitely,
• Business-related Reasons: Use of human resources from lower-cost locations or enabling the continuity of work by using engineers from different time-zones could build a good business case.

As communication is an integral part of the Scrum Framework, all Scrum Team members should pay attention to overcome the challenges to deal with working within a distributed project environment. Furthermore, all team members should have access to communication tools, including audio/video conferencing and screen sharing tools.

These commonly used project management tools support teams to enable healthy and continuous communication. Those can include product backlogs, sprint backlogs, incident lists, knowledge/ news sharing tools, and so on.

Project Organization: Multiple Teams

The simplest way of expanding the Scrum Framework while working in a larger-scale project setup is to increase the number of teams in the same location.

If multiple teams need to work together to implement a project, it is best to grow the number of teams progressively.

What does this mean to you?

Multiple Teams in a Single Location

In most organizations, progressive growth is more manageable than launching ten different new teams in one go. The best practice is to start with a single Scrum Team. After a few successful Sprints, one or two additional Scrum Teams can join the project. Once you ensure that these multiple Scrum Teams (See more about Multiple Scrum Teams) work together well, you can keep on adding further Scrum Teams to your distributed project organization.

Increasing the Number of Teams

There are two typical ways of creating new Scrum Teams:

You split an existing Scrum Team into multiple teams and add new Scrum Team members where and when necessary,

You construct a new Scrum Team from completely different engineers who have not been involved in the project so far.

Splitting an existing Scrum team has the advantage of leveraging the Scrum Team members who are already knowledgeable and who already have experience with the ongoing project.

Therefore, those new teams are usually at least at some degree productive as soon as they're formed. The major drawback of this scenario is that the existing and fully functional Scrum Team has now been split into two teams. That could always cause some issues with the motivation of Scrum Team members. Especially if those changes are happening without an in advance announcement and justification from senior leadership, and when the team members are mentally and technically unprepared.

When adding completely new teams, these already existing teams can retain their team structure and continue their Sprints. Coordination, onboarding and integration with the new teams still require attention. However, it will take longer to build up the necessary know-how and momentum to ramp-up the entirely newly formed Scrum teams.

Independent from the decision on how you add new Scrum Teams to your organization bear in mind the following principles:

• Start with a small number of Scrum teams,
• Increase the number of teams gradually,
• Ensure the continuity of work and smooth delivery of software and business value during the times of change and growth,
• If there're significant problems that hinder productivity and continuity of work, first focus on fixing them rather than the expansion with new Scrum Teams.

Project Organization: Distributed Teams

The major complexity of multiple teams manifests itself when the new Scrum Teams have to be distributed over various locations. Communication barriers between people, coordination difficulties of work, and misunderstandings of joint project norms across teams are only a few of many when it comes to mentioning this complexity.

Multiple Teams in Multiple Locations

The consequences of not addressing these challenges are severe.

Companies have to count billions of dollars of wasted IT budget because of the lack of their skills in Organizational Leadership and Scaled Scrum Expertise.

There are four critical suggestions for you to cope with these challenges:

• You ensure that new Scrum Team members are trained in the Scrum Framework as a Scaled Scrum Expert,
• You ensure that new Scrum Team members are introduced to the project adequately, so they have a proper understanding of what they're serving for. Not only technically but also from a professional business value point of view, so they can make decisions in their work to increase the value of their contribution,
• You ensure that the project norms are established. Similar to a single Scrum Team, which has its norms of how to communicate, how to plan, how to get the work done, a multiple project team organization should have its higher-level norms too. So these teams can communicate, plan, operate, solve problems, and deliver client and business value together.
• You ensure that the new team members do at least temporarily work together with the experienced project members. That could require remote site visits and on-the-job training. That's totally fine and even desired. Thanks to this approach, the knowhow can be smoothly transferred, and the two-ways and personal dialog between people in different teams and locations can be established.

Virtual Teams

Another option of a distributed Scrum Team is having its members spread over multiple locations. Such a team is called a "Virtual Team".

The main challenge here is to ensure flawless communication among the team members. Scrum Teams still need to conduct all prescribed Scrum events to coordinate their work, but now they have to do this while not all of them are present in the same room.

Virtual Teams

Team members at the same location can work together in a shared room when useful, while ensuring remote members can participate fully. And yet, they now have to rely more on the use of collaboration and communication tools. They can join the Scrum Events from the same meeting room to connect to the other half of the virtual team via video conferencing technologies.

Scrum Product Owner Team

As we have covered many times in this material so far, regular communication between the Scrum Product Owner and the Scrum Team is crucial for the successful delivery of a project.

Scrum Teams in different locations need effective access to product decisions. For a single product, the teams share one Product Owner, Product Goal and Product Backlog. The Product Owner may delegate supporting work, while remaining accountable; adding a separate accountable Product Owner for every team is not required.

This edition describes a “Scrum Product Owner Team” and a “Chief Scrum Product Owner” as an organizational collaboration pattern. A Product Owner may work with delegates or other product specialists, but these titles are not additional Scrum accountabilities and do not replace the single Product Owner accountable for one product.

The accountable Product Owner, supported by this collaboration, focuses on ensuring that:

• The correct product is built to satisfy the demands of its client,
• The Product Owner and any delegates collaborate effectively, helping the teams create business and technical value for their clients.

The Product Owner remains accountable for effective Product Backlog management. Supporting requirements work can benefit from other competencies and stakeholder input. Those can include the representatives of the business case, relevant stakeholders, enterprise architects, and technology architects.

For teams working on the same product, the Product Owner and supporting contributors work from one ordered Product Backlog toward a shared Product Goal. Each Scrum Team is responsible for delivering some of these user stories. And yet there will be still instances of specific user stories that require the attention and deliverables from multiple Scrum teams.

Component vs Feature Teams

When distributing work among different teams, we can make the teams accountable for specific software components or features. That is why we call them "Component Team" or "Feature Team."

Component Teams

When using Component Teams, each team is only responsible for the implementation of dedicated components from the overall system. To finish a user story, it is usually necessary to split the user stories into smaller pieces to implement them within a single component. The dependencies between the components of these Component Teams make continuous integration an inevitable part of successful deliveries.

Scrum Product Owner Team

These dependencies can make it harder to deliver a complete feature within a Sprint. They must be addressed through collaboration and integration: teams working on one product still need an integrated, usable Increment that meets their shared Definition of Done.

That results in increasing batch sizes and lead times of ongoing, not yet integrated work. That doesn't sound so good, because Scrum Teams should target delivering shippable software increment in smaller batch sizes and shorter lead times.

The advantage of component teams is that they make it easier to focus on and build expertise about architectural and design details of particular components. That could be massively beneficial for components that require discovery and innovation.

On the other hand, the members of component teams do only specialize in individual components of the whole system. They could lose their bird-eye view and business necessity of features.

Keep in mind that our clients do not compensate us to deliver components, but features with which they will execute their businesses. Without this relentless focus on features, overall optimization, and integration of software might take extra time. Since decisions of component teams tend to optimize single components, those decisions can construct invisible bottlenecks for the success and performance of the overall solution.

Component Teams

Feature Teams

Feature teams are fully responsible for the implementation of user stories as they're specified within the Product Backlog. The teams do no longer need to be divided for various components. Each Feature Team is responsible for delivering a fully-functional feature and a business value associated with this feature.

Feature Teams

Members of feature teams possess cross functional skills. They act as autonomous as it is possible to deliver fast. The advantage of feature teams is that the team maintains the system-knowledge, and this makes it easier for them to integrate their features with the rest of the system.

However, for feature teams, it may become more challenging to build sufficient know-how about components. Furthermore, bringing up an autonomous feature team that can deliver fast and independently takes time as building an interdisciplinary functional team is not that easy. And yet, these are the high-performer teams which get the job done in most organizations, probably including yours.

How Do We Choose Component Teams vs Feature Teams?

In practice, most of the large organizations use both dedicated Component Teams and Feature teams too.

Component and Feature Teams

Team C, on the chart, is a Component Team. It provides planned and on-demand infrastructure services to other teams that function as Feature Teams. Team C does not directly implement end-to-end user stories per se. They deliver the requirements of the user stories committed by the Feature Teams.

That allows the minimization of the number of qualified people in Feature Teams with the know-how of those components.

The Scrum Master In The Distributed Project Environment

In a distributed project environment, the role of the Scrum Master is even more essential. In those project configurations:

• There will be extra effort required to align the teams on the values of the Scrum Framework,
• It will take longer to establish individual team and project norms (standards) which influences numerous teams,
• Last but not least, there will be many impediments due to the increased number of dependencies between teams and their deliverables.

A Scrum Master needs to be accessible and effective in supporting the team. Physical co-location can help, but it is not a Scrum requirement and remote support is possible. Distributed arrangements should enable the Scrum Master:

• To help cause the removal of impediments to the team’s progress,
• To help the team establish effective working agreements, and
• To help them to improve their use of the Scrum Framework.

Some organizations use a Lead (Primary) Scrum Master to support cross-team coaching and coordination. This is an optional organizational pattern, not a required hierarchy or a replacement for each Scrum Team’s accountabilities.

Each Scrum Team within the larger organization still has the Scrum Master accountability and needs effective support for its own events, self-management and improvement.