Distributed & Large Scrum Projects - International Scrum Institute
The Scrum Framework - as described so far - works best for a single Scrum Team in one location. However, in reality a single Scrum Team often cannot realize projects or resources are spread over multiple locations. As a consequence the number of teams has to be increased and/or the teams will be distributed. The reasons for this can be technical (e.g. experts are not available locally), size-related (project too big) or business-related (e.g. usage of resources in low-cost countries or speed-up by usage of different time-zones).
As communication is an integral part of the Scrum Framework, special care had to be taken to overcome the challenges when working within a distributed environment. Therefore all team members should have access to the appropriate communication tools (e.g. video conferencing and web cams) to breaking down the more tangible communication barriers.
Project Organization - Multiple Teams
The simplest way of extending the Scrum Framework when working in a large-scale project is to increase the number of teams in the same location.
Multiple Teams in a Single Location
If multiple teams have to be used to implement the requirements it is important to make sure that the number of teams does not grow too fast. Best is to start with a single team and after the first sprints have been completed adding a small number of other teams. If required after these teams are productive other teams could be added.
Increasing the Number of Teams
For creating new teams there are two possibilities:
- Splitting an existing team into new teams and add new members
- Adding completely new teams
Splitting an existing team has the advantage that the required know-how is already available in the team and the team can get productive faster. The drawback is that already working teams are torn apart.
When adding completely new teams, these existing teams can continue with their work without much disruption. However, it will take longer to build up the necessary system-know-how in the new Scrum Team.
Independent from the decision how to add new teams the following rules should be followed:
- Start with a small number of teams
- Always wait until a foundation is build and the teams have stabilized
- Increase the number of teams in small steps
Project Organization – Distributed Teams
Even more complicated it will get if these new teams are distributed over multiple locations. Now also more often communication obstacles will occur and special care has to be taken to introduce and involve all team members adequately.
Multiple Teams in Multiple Locations
To make sure that new team members are introduced adequately and build-up the required knowledge as fast as possible, new team members could e.g. temporarily added to an existing team, preferably even in another location. With this approach the know-how is transferred and personal relationships with people in other teams and locations build.
Virtual Teams
Another possibility for distribution is that the team itself is spread over multiple locations. Such a team is called a "virtual team".
Virtual Teams
The main challenge here is to ensure good communication between the team members since some people might not be able to physically participate in meetings or have no access to "communication helpers" like the Sprint Board.
One possibility would be to use collaboration and/or communication tools. Co-located people could then e.g. be added to meetings via video conferencing or the meetings could even be performed completely in a 'virtual room' provided by most collaboration platforms.
Scrum Product Owner Team
Proper communication between the Scrum Product Owner and the team is crucial for successful implementation of the project. To ensure that the Scrum Product Owner is always available to the team, it is often necessary to have multiple Scrum Product Owners working together. Ideally there is one dedicated Scrum Product Owner per team.
The Scrum Product Owners should then build a dedicated Scrum Product Owner Team to effectively work together. One of the Scrum Product Owners should be assigned the role of the 'Chief Scrum Product Owner' who is responsible to ensure that the product is developed in a coordinated fashion.
Since this team is responsible for the complete requirement engineering it might also be beneficial to add other roles and stakeholder like architects or customer representatives.
Scrum Product Owner Team
All Scrum Product Owners should work within a single Scrum Product Backlog containing all stories relevant for the project.
Component or Feature Teams
When distributing work we can slice the teams in different manners: as Component or Feature teams.
Component Teams
When using Component teams each team is only responsible for the implementation of dedicated components in the system. To finish a user story it is in most cases necessary to split the stories into smaller pieces that could be implemented within a single component. The resulting dependencies between the teams make integration on a regular base necessary. In many cases a single user story cannot be finished within a single sprint as implementation in one team depends on the results of other stories in other team that are not yet available. This is called "Pipelining" and should be avoided as far as possible.
Component Teams
Advantage of using component teams is that it is easier to ensure proper architecture of the system. On the other hand people specialize only on small parts of the system and knowledge about the system as a whole might get lost. Without this knowledge local optimization might take place since the team might sometimes make decisions that are optimized for the single component but better solutions from a system perspective could have been made.
Feature Teams
Feature teams are fully responsible for implementation of user stories as contained in the Scrum Backlog. The team is not longer sliced along system components but implement everything what is necessary to finish the story.
Feature Teams
Feature teams have to be interdisciplinary and ideally can act completely autonomous. The advantage is that system-knowledge is spread and integration is easier. However it is more difficult to ensure consistency of the system architecture and it might be difficult or takes time to ensure that enough knowledge is available in all teams.
Component and Feature Teams
In reality many larger projects use both: dedicated Component teams and Feature teams.
Component and Feature Teams
Team C is a Component team and provides necessary infrastructure services to the other teams that are used as Feature teams. Team C does not directly implement user stories but get the requirements from the user stories committed by the Feature teams. This allows minimizing the number of required people with expert knowledge (e.g. databases know-how).
The Scrum Master in a Distributes Environment
In a distributes environment the role of the Scrum Master is even more important as such setups usually have more impediments that require the Scrum Masters attention and effort.
One important rule is that the Scrum Master has to be located where the team is otherwise it will be difficult to remove the obstacles in daily work. There should always be a primary Scrum Master, but in virtual teams it might also be an option that on the remote site one person acts as a local Scrum Master.
Share It With Your Colleagues and Friends to Help Them Learn:
Distributed & Large Scrum Projects - International Scrum Institute
|
|
|
|
|
|
|
SCRUM INSTITUTE™
