Category: Distributed Agile

Conducting the daily Scrums when team members are in the same time zone and speak the same language is much simpler than for a team with members spread in multiple countries and time zones, having many different languages and cultures.

Following are some my recommendations for handling Distributed Daily Scrums.

• Ways of communicating during the daily Scrum: Having face-to-face daily Scrum meetings gives the team the highest level of collaboration possible.
• Teleconference meeting: Distributed teams with overlapping work hours should use a teleconference call to the same phone number every day to hold their daily Scrum meetings.
• Videoconference meeting: The main advantage of this approach is that team members get to see one another, so there is less nonverbal communication loss.
• Approach to handling time zone issues: Distributed teams can use methods such as Daily Scrums through documentation, liaison approach, alternating meeting times, and share the pain to deal with distributed daily Scrums where the team has members with no overlap in their work hours.
• Background noise can be distracting on a teleconference, so teams should chose a quiet room to conduct the meeting.
• Keeping the team engaged: Possibly the best way to stay engaged and to make sure that others on the team stay engaged is awareness i.e. build awareness of what the team is working on.
• Facilitating the meeting: In a distributed environment, as individuals come into the call, they will identify who they are. The Scrum Master calls each person and asks for their response. They may respond in the order they arrived at the teleconference or the Scrum Master may choose to call on each person.
• Taking daily Scrum notes: This helps the distributed team members overcome language problems, plan and learn. Chat Tools help distributed teams do daily Scrums.

I have been working in Distributed Environment most part of my professional life. I have worked with US-India, India-Malaysia, India-Malaysia-Thailand, India-China and various other challenges. The geographical distances, cultures, language barriers, work-styles post challenges for most teams.

Following is a consolidation of various learning I had while working with Distributed teams. I believe, most of the challenges would be similar and therefore most of the learning that I had would be applicable to you too.

• 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.