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.
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 to determine dependencies. For example, the first session focuses on identifying major tasks, deliverables, and high-level dependencies. During the second session, each team member defines activities and provides estimates for each task he accepted while identifying dependencies (on other activities) to start and complete his tasks. This results in better alignment of Sprint teams and more accurate Sprint plans.
5. Daily Scrum Meetings
Daily Scrum meetings are generally held in one common room and include Product Owner and Scrum teams that handle issues in real time. Because of time-differences, the offshore team doesn't get real time input from the U.S. on requirements changes and technical issues. Even a one day wait time in the Sprint cycle will result in lower productivity. It can be beneficial for the Product Owner ("chicken") from the onshore team to be part of the daily Scrum meeting for some period with the offshore team to help resolve the impediments online. If timing for the morning Scrum meetings in India is inconvenient for U.S. team members to attend, then a shortened session is scheduled at the end of the day in India with the specific person from the onshore team like a domain expert ("pig"), technical or QA lead, depending on the nature of the impediments. Gaining real time inputs allows greater flexibility and response to requirements changes and cross-team dependency issues.
6. Offshore Development Manager as Scrum Champion
Agile is a type of iterative development process, but not every iterative development process is Agile. More than being time-boxed iterations, there are lot of other aspects to Agile methodologies such as self-managed teams, adaptability, and less command and control. So, it is absolutely necessary to have a Scrum champion offshore to guide the team. Preferably, the Scrum Champion on the offshore team has prior experience using Scrum or can undergo Certified Scrum Master training through a company like Boulder, Colorado-based Rally Software Development. Otherwise, the offshore team will end up running mini-waterfall projects inside the iterations, not Agile Scrum.
7. Configuration and Build Management
Builds are usually completed in one location with a single code base, several times a day. However, with teams located 8,000 miles apart, bandwidth challenges make it difficult to ask the offshore team to check code into an onshore code base directly and to create builds from that code base. In a successful global Agile environment, onshore and offshore teams will work on the same code base by setting up replicas that get merged both ways daily. For example, the India team takes ownership for the code base in their morning, and hands over the code base to the U.S. team at the end of the day with a successful build, using build manage/software configuration management tools such as Perforce, Rational and Subversion. This approach helps the continuous integration of multi-shore teams.
8. Sprint Demonstration
Onshore Scrum teams usually demonstrate software at the end of each Sprint. In most cases, the Product Manager is situated onshore and the Business Analyst on the offshore team acts as pseudo Product Owner. When functionality changes or additions occur during a Sprint late in the process (due to lesser communication with Product Owner compared to the onshore teams), there is not much time for the team to respond. As a result, the Sprint backlog overflows into the next Sprint. We suggest modifying this process by inserting an informal "Mid-Sprint review/demo" with the Product Owner after approximately two weeks. This gives the offshore team time to react to changes in the specification while there is still time remaining in the current Sprint cycle, thereby reducing the backlog carried over to the next Sprint.
9. Scrum Team Collaboration
Standard Scrum teams meet daily for 15 minutes to share what was done the day before, address the plan for the next eight hours, and discuss any impediments. In some cases, the offshore team may feel that it is being micro-managed as a result of the inherent emphasis on status and detail, and this can lead to lower productivity and morale. This meeting can very easily drift toward becoming a traditional status reporting meeting with the Scrum Master on a daily basis. Restructuring daily meetings to better reflect the spirit of Agile development helps these daily sessions become more informal by emphasizing information sharing and collaboration to solve challenges. This restructuring helps team members feel empowered and less intimidated about sharing status and results.
10. Adhering to Standards
Offshore organizations that follow processes like CMMi may expect Scrum teams to also adhere to rigid processes, documentation, and reporting - thereby making the Agile Scrum teams more and more process-driven rather than people-driven. Tailoring the standards to reflect specialized processes and metrics in line with Scrum timelines enables the nature and benefits of Scrum to remain intact. In talking with hundreds of software companies each year, we see less than one quarter that have a CMMi assessment. It is possible to be assessed at CMMi and operate with Agile processes, but we don't see the benefit of the combination. In our view, CMMi is all about stringent adherence to process, heavy documentation, and intense tracking of activities. Agile is all about light documentation, process serving the team versus the team being bound by process, and a focus on deliverables versus how deliverables were achieved.
Conclusion
Adopting a Global Agile approach is indeed possible and beneficial to software companies that choose to embrace it. In addition to tangible benefits including reduced calendar time to implement new features or enhancements, there are powerful morale-building benefits of this process as well. By following these ten steps, pioneering software companies can create a productive, integrated multi-shore development team that doesn't get bogged down in bureaucratic processes. By creating a culture of trust and collaboration, all stakeholders can "feel" the product enhancement much earlier. This is especially valuable with geographically dispersed teams, enabling members to gain wider product knowledge in a short period, enhancing flexibility in resource deployment. Scrum is the best way for the onshore team to get real updates on the offshore team's progress with demonstrable software every month versus numbers and graphs.
About the Author
Balasubramaniam "Bala" Muthusamy has extensive experience practicing Agile Scrum methodologies. Additionally, he has 13 years of experience in consulting, support, and product development for enterprise applications including ERP, supply chain, and project management software. Bala earned a bachelor's degree in production engineering along with various certifications in the supply chain management domain and J2EE.
