Distributed Scrum Teams
Today businesses are shifting to emerging economies (such as India) due to reduced business operations cost and an easily available workforce. The businesses certainly are more virtual and distributed, with “distributed” as its key element. Thus the need for better managing such teams, using the right tools and processes, is becoming increasingly critical for any enterprise company.
Here are some reasons for the shift and need for having distributed Agile teams:
- Globally distributed teams reduce costs.
- They can reach the market more quickly with a “follow the sun” model.
- Distributed teams expand access to new markets.
- Acquisitions as a result of consolidation results in companies working together to integrate their businesses.
- Expansion can aid innovation and thought leadership.
- Telecommuting gives options for communicating with teams effectively.
- Collaboration tools — improved tools for distributed communications and server-based, multiuser tools for product development — are removing barriers, and more teams view distributed collaboration as an alternative.
Handling Distributed Scrum Teams
- Distributed teams increase the need for clear, timely communication between sites. You might be thinking of increases in complexity due to more time zones, language barriers, and cultural differences getting in the way.
- Communication is the core issue among the distributed teams. Different time zones, conflicting working hours, cultural and language barriers impact communication and collaboration.
- Investing in effective enterprise tools for requirements repositories, source Control management, build and deployment setup, defect tracking, and project management tools is essential.
- Practicing Test Driven Development (TDD), Continuous Integrationand Automation of Testing are recommended
- Proper communication setup such as telephones and videoconference are essential in a distributed setup.
- Telecommunication etiquettes such as conversation using round-robin technique, importance of mute etc are essential hence a upfront training or setting ground rulesfor telephone etiquette is essential.
- Coordinating Agile and non-Agile teams: Making sure the non-Agile team is aware of the priorities of the Agile teams and keeping dependencies visible can help to prevent blockers between the teams.
Collaboration within a Sprint
- Scrum Teams should follow continuous integration, test automation, and test-driven development practice to foster distributed collaboration during the sprint and help teams complete user stories within a sprint.
- Documentation helps to overcome distance: Because of language barriers, distributed teams often need more written documentation than co-located teams.
- Using the right tools: In a distributed environment, right tools and effective practices can help team members communicate more effectively.
- Valuing the whole team: The Scrum Master should focus on an “us” versus a “them” attitude in the distributed team, due to more delays in communications and fewer opportunities to work together.
- Transparency: Distributed Agile teams should use project management tools to identify tasks that are open, in progress, and completed so everyone is aware of the current status.
- Dealing with defects: Distributed teams may want to consider creating a user story with a certain number of story points in the sprint to deal with the problems, or they can set a priority for the maintenance tasks as per the customer log, or create a sub-team to focus only on handling these issues during the Sprint, or — depending on the skill set of the technical support team — make the necessary code changes.
- Handling blockers during the sprint: In the large-scale enterprise transitioning to agile, the Scrum Master needs to hear from distributed Scrum team members who are facing blockers and dealing directly with inhibitors will help increase the velocity of the team over time, as well as the velocity of other teams as they transition to Scrum.
- Responding to questions during the sprint: For enterprise product development, the Product Owner should look for ways to match representative stakeholders with the teams’ working hours and to be available during that time as well.
- Sharing time zone challenges: One approach to help manage such cases is to make sure that distributed teams in different time zones are fully self-sufficient and the team spreads the work to minimize dependencies.
- Automation and Continuous Integration
o Continuous integration: This is the key to delivering stable, high-quality code consistently and quickly, which results in reducing time to market for any distributed Agile team.
o Report any build failures to the team: Allows the distributed team to know the current state of the code in the integration branch of the source control system, generating a notification for build success or failure.
o Reduce the risk of integrating code: Continuous integration ensures that a build runs regularly and allows the distributed team to identify integration issues earlier when they are less costly to fix.
o Automated Test Cases: When developers are doing the unit testing of their code, they should also create automated unit tests as continuous integration certifies every build, developers can make changes with more confidence, and the entire team can remain in sync with the latest build.
o Improve the efficiency of the team: Distributed teams’ efficiency can be improved by automating once and then reusing as much as possible. This removes human error, provides consistency, and frees up people to do higher-value work.
o Builds can run at different frequencies: Setting up the hourly build helps the distributed team know about a failure closer to the time of the code integration, and team members can take action on it earlier.
o Test automation: To streamline the testing and help the distributed team get as much done as possible within a two-week sprint, teams should automate time-consuming manual processes where possible.
o Dedicated automation teams: The developers in distributed teams should tell what is ready to be automated to allow testers to closely couple with the product.
- Test-driven development: Developers write unit tests, the small tests that fail first. Testers work with developers to ensure that any later tests do not repeat the work the developers have already done.
o Provide documentation and working examples of code: Developers are writing their unit tests and providing documentation and working samples for the code they are testing. This allows other team members to gain a quick understanding of the code when they need to work with it.
o Help reduce the time to fix defects: The developer may be able to create a unit test specific to the case that is causing the problem and fixing the area where the problem is occurring. The developer can save the time needed to create a full build, start the application, get to the right place, and test the fix manually.
o Help improve code quality and provide a safety net for changes: An early defect detection process helps developers improve the code knowing the existing set of tests will detect any problems. Developers can think of code in small units that they write, test independently, and integrate later.
o Help team members work together and collaborate: When teams are evolving from a traditional development model to Agile, it is a huge attitude shift to adopt TDD.
o Help teams move away from big up-front designs: Break down a feature into smaller testable chunks and create small teams to start working on some code right away. This code can be small prototypes that act as tracer bullets through slices of functionality.