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.
As we navigate the complexities of Distributed & Large Scrum Projects, our journey thus far has unveiled the fundamental principles and strategies to conquer the unique challenges posed by expansive projects and remote teams. Building on this foundation, we're now poised to elevate your expertise with time-tested protips and real-life case studies, tailored for serious professionals seeking mastery in this domain.
Enhancing Your Approach: Protips and Real-Life Insights
1. Scaling Success: Maria’s Story
In a global software rollout, Maria, a seasoned Scrum Master, faced the challenge of coordinating multiple teams across continents. Discover Maria's approach to synchronizing efforts, mitigating communication barriers, and fostering collaboration amidst geographic dispersion.
2. Team Dynamics: The Case of Jimmy and Julia
Explore how Jimmy, a Product Owner, and Julia, a Scrum Developer, navigated the intricacies of a Large Scrum Project, managing divergent expectations, and leveraging agile methodologies to streamline workflow and maximize productivity.
3. Adapting to Change: Insights from Robert
Join Robert, a Scrum Professional, in examining the pivotal role of adaptability in a distributed Scrum environment. Learn how Robert steered a project through unforeseen challenges, demonstrating resilience and innovative problem-solving.
4. Leadership in Complexity: Lessons from Melinda
Dive into the leadership journey of Melinda, a Scrum Team Lead, tasked with orchestrating a large-scale project with multiple stakeholders. Uncover the strategies employed by Melinda to navigate complexities and maintain alignment across diverse teams.
Why These Insights Matter
These insights transcend theoretical frameworks, offering tangible wisdom gleaned from real-world scenarios. Embrace these narratives as guideposts, enriching your understanding of Distributed & Large Scrum Projects beyond the confines of theory.
Embark on this enriched exploration, fortifying your expertise with practical wisdom, and uncovering the nuances of successful project management in expansive and distributed Scrum environments.
Implementing Insights: Actionable Strategies
5. Cross-Cultural Collaboration: Nathan's Approach
Discover how Nathan facilitated seamless collaboration among culturally diverse teams. Uncover strategies employed by Nathan to bridge communication gaps and foster a cohesive, inclusive project environment.
6. Agility at Scale: Lessons from Pat
Join Pat, a Scrum Coach, in dissecting the intricacies of scaling agility within a large project framework. Learn from Pat's experiences in aligning multiple teams and maintaining agility amidst complexity.
7. Remote Dynamics: Terry's Journey
Explore Terry's journey as a remote Scrum Master, navigating the challenges of distance, time zones, and asynchronous communication. Gain insights into fostering engagement and accountability within a distributed team.
Leveraging Collective Wisdom
These narratives encapsulate invaluable wisdom from professionals immersed in the realities of Distributed & Large Scrum Projects. Embrace their experiences as catalysts for refining your strategies, aligning your practices with the dynamic demands of large-scale project management.
Navigating Complexity with Confidence
By immersing yourself in these real-life case studies and protips, you're equipped not only with theoretical understanding but with actionable insights that transcend geographical boundaries and project scopes. Let these narratives guide your approach, empowering you to navigate complexities with confidence and finesse.
Conclusion
As our exploration expands to encompass these diverse real-life scenarios and insights, we invite you to absorb, reflect, and implement these learnings in your own professional endeavors. The world of Distributed & Large Scrum Projects thrives on adaptability, collaboration, and innovative problem-solving—qualities beautifully exemplified by the experiences shared here.
Engage with these narratives as a testament to the versatility and efficacy of Scrum methodologies in diverse project landscapes. Embrace the wisdom offered by these professionals, and let their stories become guiding beacons in your pursuit of excellence in Scrum project management.
Share It With Your Colleagues and Friends to Help Them Learn:
Distributed & Large Scrum Projects - International Scrum Institute
|
|
|
|
|
|
|
SCRUM INSTITUTE™
