Successful extended global development teams have adapted Agile methodologies such as XP, Scrum and DSDM to further improve response to customer needs and time to market. At the same time, they gain rapid knowledge transfer, training, transition planning, goal setting, governance, as well as the comprehensive operational reviews required to achieve results. There can certainly be challenges employing Agile development methodologies in a multi-shore environment.
However, our customer research indicates that with the proper modifications to accommodate multiple locations and time zones, offshore engineering teams can deliver equivalent levels of quality and productivity as established U.S.-based Agile teams in just three months - including reduced calendar time to implement new features, early development feedback and the ability to make critical course corrections. It all starts with adapting Scrum to offshore development by implementing changes to how engineering teams plan, communicate and collaborate.
1. Scope of Work for Offshore Scrum Team
It's important to identify modules or work where there are minimal dependencies between onshore and offshore teams, such as parsing work efforts so offshore and onshore developers do not have to be in constant communication over the development of a specific feature or function. For example, it's counterproductive to have an onshore and offshore developer both checking in code into the same section of the code repository and potentially impacting each other's code when multiple daily builds are conducted. Also, having self-sufficient and self-organizing teams with business analysts, programmers, QA staff, and technical writers will allow the offshore team to conduct work independently while reducing communication delays due to time zone differences.
2. Physical Proximity
Multiple Scrum teams distributed across the U.S. and offshore locations result in fewer interpersonal working relationships due to minimal "live" contact between Scrum teams. Lack of contact can affect quality and productivity and cause misunderstandings related to deliverables. To tackle this problem, we recommend basic team building exercises. For example, consider sending the entire offshore Scrum team to the U.S. for a few weeks at the outset to observe team dynamics and a typical Sprint, and build relationships with U.S. based Scrum teams. Going forward, it is suggested that approximately once every two months a U.S. based engineer visits and interacts with the India team, and then leads members from the India team to visit the U.S. every six months. This effort helps the offshore team feel connected and creates a better sense of understanding between the two teams, especially from a cultural and morale-building perspective. Assigning a senior technical person to the offshore team for a longer duration will further decrease ramp up time and ease integration of work cultures.
3. Scheduled Interaction
Typically, multiple Scrum teams have regular interactions throughout the day for Sprint Planning, Demo, etc. With distributed Scrum teams, using technology to support multiple forms of communication such as daily scheduled phone calls, emails, chat, video/web conferencing (such as Skype) and threaded discussions are crucial to simulate the benefits of in-person interactions. Scheduling interaction versus having it take place in an ad hoc, informal manner ensures that interaction occurs in a structured, valuable manner.
4. Sprint Planning
Sprint planning usually kicks off with a single eight hour session attended by all stakeholders. But it is difficult to determine cross-team dependencies in one session, especially one that is at the mercy of different time zones. One solution is to replace the initial eight hour session with two separate four hour sessions conducted over two consecutive days. Splitting the sessions gives team members more time to determine the best allocation of effort across teams (onshore and offshore), and an ability to analyze efforts