Scrum Institute, Scrum Framework Episode #14 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org

You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play.

Listen to Scrum Institute Podcast on Apple
Listen to Scrum Institute Podcast on Google Play
Listen to Scrum Institute Podcast on Spotify
Listen to Scrum Institute Podcast on Listen Notes
Listen to Scrum Institute Podcast on Castbox

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.

As a consequence, the number of teams has to increase with various distributed teams. 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. So the Scrum Team has to be distributed,
• 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 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 haven’t involved the project so far.

Splitting an existing Scrum team has the advantage of leveraging the Scrum Team members who are already knowledgeable and who have already experienced 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 continue with their Sprints without any interruption and extra integration effort. 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 andScaled 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 Team members must still need to conduct all Scrum Rituals (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

Scrum Team members co-located in the same location should still work together in the same room. 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.

We need to ensure that the Scrum Product Owner is always available to Scrum Teams located in different locations. Therefore, it is often necessary to have multiple Scrum Product Owners working together. Ideally, there is one dedicated Scrum Product Owner for each team.

The Scrum Product Owners should then build a dedicated “Scrum Product Owner Team” to work together effectively. One of the Scrum Product Owners should be assigned to the role of the “Chief Scrum Product Owner”.

He or she is responsible for ensuring that:

• The correct product is built to satisfy the demands of its client,
• All Scrum Product Owners collaborate efficiently, and they enable their teams to build the business and technical value for their clients.

Since the Scrum Product Owner Team is responsible for the complete requirement engineering, it is beneficial to have other competencies and stakeholders in this team. Those can include the representatives of the business case, relevant stakeholders, enterprise architects, and technology architects.

All Scrum Product Owners should work within a single large Scrum Product Backlog containing all stories relevant for the project. 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

Thus, a feature cannot be usually delivered within a Sprint because its implementation depends on the deliverables from user stories of other teams.

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.

One important rule to bear in mind that the Scrum Master should physically locate where his or her team is. Otherwise, it will be almost impossible for the Scrum Master:

• To remove the impediments for his team,
• To Establish their norms, and
• To help them to improve their use of the Scrum Framework.

The best practice is to have a Lead (Primary) Scrum Master to guide the overall use of the Scrum Framework across multiple teams.

In other unit Scrum teams, which form the larger Scrum organization, someone should be acting as a local Scrum Master too.