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
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:
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.
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.
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:
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.
There are four critical suggestions for you to cope with these challenges:
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.
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.
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 diﬀerent 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:
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.
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.”
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.
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.
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.
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.
In a distributed project environment, the role of the Scrum Master is even more essential. In those project configurations:
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:
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.