Following the sun: case studies in global software development.

INTRODUCTION

Global telecommunications networks have matured in the past decade, providing a vehicle for relatively inexpensive communication between teams that are separated by great physical distances. This new reality provides an opportunity for teams to collaborate in a much more effective manner than ever before. Because the teams are now able to communicate effectively and economically, they can work together on common goals with groups who are located not only in different regions of their native countries but also across the entire globe. Many new tools that enable this type of collaboration have emerged, and although these tools greatly reduce the effects of physical distance, a new separating factor has been exposed; that presented by significant differences in time zone.

For example, in order to communicate in a form other than e-mail, leaders of teams (if not the whole team itself) are often forced to work well outside of their normal working hours. This is inconvenient at best and completely unworkable at worst. Although problems such as this exist, it may be possible to exploit the phenomenon of global software development in a positive manner, giving the distributed team a competitive advantage.

In this paper, in the context of two globally distributed software development projects, we examine whether it is possible to create a development environment in which tasks can be assigned in such a manner that work can "follow the sun." We examine the effects of moving work across the globe so that each team is working during their local normal business hours and assigning or handing off tasks at the end of their day to teams that are beginning their normal work day, effectively yielding a 24-hour development clock. There are advantages and disadvantages to using this method, and we explore these in the context of two case studies. In the first case study, it was possible to use this approach successfully; in the second, a series of projects met with greater challenges. We examine, in depth, which factors were most influential regarding the success of the respective efforts and which factors limited it. Because the workforce is becoming increasingly global in nature, we conclude with a discussion of best practices for using this global workforce to its maximum potential, thus creating higher value for customers and increasing the ability to compete in this new marketplace.

Related work

Although little has been published regarding a "follow the sun" approach to global software development, the topic of global software-development practices has been the subject of much discussion in recent years. The general consensus has been that globalization introduces a great deal of complexity to an already complex process. Specifically, the use of globally distributed development teams has been found to extend time lines and to require more development resources in order to complete a project of the same complexity when compared to projects staffed with collocated teams. (1,2) A major factor that has been repeatedly discussed is the loss of informal communication channels, which occur naturally in collocated teams. (1,3-7) The loss of these channels, which are often taken for granted when all team members are in the same location, has been found to make it increasingly difficult to find experts who can answer questions, (1) and can lead to a loss of trust between team members in different locations. (3,8) In addition to these social challenges, the effect that the loss of communication has on the requirements management process is discussed in Reference 9, whose authors are among the few to note that time zone diversity can be viewed as an advantage.

Suggestions for mitigating these problems are discussed in Reference 3, whose authors propose the inclusion of face-to-face kickoff meetings, recurring face-to-face meetings among the team leaders when possible, increased cultural awareness training for the teams in general, and the implementation of tools that help to re-enable informal communications. A discussion on how to address communication issues from an organizational perspective is presented in References 9 and 10, and it is argued that for distributed teams in particular soft skills (such as those related to social interaction) might be even more critical than technical skills (such as those related to tool deployment).

Iterative development methodologies have been found to be helpful in mitigating some of the risks inherent to global software development, as they help build trust between distributed teams by forcing synchronization by requiring frequent deliverables. (3,11) A case study evaluating this approach in terms of the "eXtreme" programming model is presented in Reference 12.

An interesting set of patterns and "anti-patterns" (i.e., methodologies that consistently produce unsuccessful projects) for effective global software development is proposed in Reference 13. The problem of globally distributed code control systems is discussed in Reference 14. A study of global software development from an anthropological viewpoint is presented in Reference 15, whose authors agree with previous work (9) that most failures are not due to tools, but to a web of social factors, not one of which can be blamed exclusively.

CASE STUDY: BUSINESS INTELLIGENCE

This case study focuses on a project whose goal was to deploy a second instance of a custom-built business intelligence solution. The original solution was designed, developed, and deployed in the United States. The second instance was to be deployed at an IBM location in Australia. While some of the components of this project were commercially available software products, the middleware layer was comprised of custom-built application code which required significant generalization and rework before the second instance could be deployed.

The project was broken into four major phases. The first phase was the infrastructure set up at the data center in Sydney. The second phase consisted of creating the required installation scripts for the data warehouse and later building the warehouse on the Australian infrastructure. The third phase comprised the writing of the front-end Web page code. The fourth phase consisted of the design, test, and deployment of the middleware code used to collect the data from the source systems and populate the data warehouse so that the front-end Web pages could display the results.

The teams

In order to complete this project, we were required to merge two geographically distant development groups into one cohesive team. The local development team was based in Boulder, Colorado. The Boulder team also had a management sponsor and an executive sponsor who assisted with the resolution of any business-related issues. The remote team was distributed across three locations in Australia. The discussion in this paper is limited to the interactions between the teams as they occurred over international boundaries and does not discuss the dynamics between the three teams in Australia.

Challenges

Because this was a custom-built solution and not a packaged software product, there were no ready-made installation scripts. Much of the code was specifically tailored for the Boulder environment and as such, required significant modification before it would function properly in the two data centers simultaneously.

The two teams had never met each other face-to-face. When the project was first proposed to the sponsoring executives, the two teams, with no previous experience working together, had to present a unified front in order to secure funding. The lack of previous experience working together between the two teams and the resulting lack of mutual trust made promoting the business case difficult. When a development team is collocated, trust generally develops early in the project. Unfortunately, before we could secure funding for face-to-face meetings, we had to convince our sponsors that the project itself was worth doing. As such, the early phases of the project had to be completed before the two teams met in person. Funding for future phases was contingent upon successful completion of the proof of concept.

Our approach

After funding was secured for the initial phase, the lead developer of the Australian team flew to Boulder for two weeks of training on the various components of the solution. These two weeks served a dual purpose. The primary purpose, as perceived then, was to bring the development team in Australia up to speed on the inner workings of the code that would be deployed in Australia. The secondary goal was for this developer to meet the team in Boulder so that he could associate faces of team members with their names when questions arose. Building personal knowledge about the team and building mutual trust, however, was actually more important than resolving the technical issues. It was, in fact, this trust which allowed us to resolve future technical issues efficiently by conference calls that stretched halfway around the world. This foundation of trust resulted in increased efficiency.