LEARNING OBJECTIVES
To understand the main issues that impact global software development
To know different approaches for addressing the challenges of global software development
Note
In global software development projects, work is distributed over sites that operate in different time zones and geographical locations. People working at these different sites may differ widely in culture. The specific challenges imposed by this distance in time, place, and culture are discussed in this chapter. These challenges concern the way people communicate and collaborate, and the way work is coordinated and controlled.
A friend of mine runs a small Dutch software company that develops websites for organizations such as healthcare insurance agencies and municipal bodies. The requirements engineering and design is done in the Netherlands. Implementation and unit testing is outsourced to an Eastern European partner. Management and acceptance testing is again the responsibility of the Dutch company.
The reason for this division of labor is primarily cost – at the time of writing, salaries are still quite a bit lower in Eastern Europe than in the Netherlands. The technical competence of the Eastern European partner is very high. Consequently, the technical quality of their work is very high as well. But they have much less feeling for user interface issues. As long as all items appear on the website, they do not care so much about fonts, colors, and the like. The end result is that a lot of extra communication about these user interface issues is required, and the result often leaves much room for improvement.
Until fairly recently, software development was mostly a collocated activity. Today's software development often is a global activity. The challenges of the globalization of software development are discussed in Section 20.1 and Section 20.2 discusses ways to tackle these challenges.
Members of a collocated development team are usually housed within walking distance. Psychology tells us that if one has to walk more than 30 meters or climb the stairs, one is inclined to reinvent the wheel rather than ask a colleague. So, preferably, development teams share a project room or a 'war room'. Experimental studies such as (Teasley et al., 2002) confirm that the frequent informal exchanges that result from being collocated foster collaboration, information sharing, mutual learning, and efficient communication. Communication between developers that are more than 30 meters apart is as infrequent as communication between developers at different sites. This is just one challenge of being global.
The tasks of the members of a software development team are interdependent. They coordinate their activities to reach a set of common goals and share the responsibility for reaching those goals. Traditional, collocated software development fits this picture. A global, or virtual, team has the same goals and objectives, but it has multiple sites. It operates across different time zones and geographical locations, and may involve different organizations. Members of a virtual team use a variety of media (telephone, email, teleconferencing, etc.) for communication.
Many organizations have outsourced or offshored[35] part of their work to lower the labor cost. Currently, mostly the 'low-end' tasks are offshored to low-wage countries, while 'high-end' activities such as requirements engineering and architecture remain in high-wage countries. It is by no means sure that situation will continue (Aspray et al., 2006). But other factors also play a role when deciding on where to locate software development activities:
faster delivery because of 'follow-the-sun' development: Software development is started by a team of developers at one development site and, when their work day ends, it is shifted to a team in a place where the work day is starting. In theory, work can continue around the clock.
access to a larger pool of developers: In some countries there is a permanent shortage of skilled developers. To alleviate this problem, work can be moved to a country where there is an abundance of skilled developers.
better modularization of work: By its nature, global development requires that work is split into modules that require as little communication between development teams as is possible. Global development thus encourages desirable design properties.
There is very little proof that these alleged advantages actually materialize (Conchúir et al., 2006). For example, around-the-clock development often results in working shifts that overlap in time, so that developers at different sites can have direct contact. Work then shifts to these overlapping hours. It may also result in a lot of overtime at either side to make sure that direct contact is possible. Cost advantages are offset against higher travel costs, higher maintenance costs, and so on. Even if the wages at offshoring sites are about 10% of those in the Western hemisphere, actual cost savings are more likely to be in the 20–40% range (Matloff, 2005).
The essence of a collocated team is that many things are shared. The team shares some set of tools and uses the same process. Team members have the same background and share an understanding of the job to be done. Team members share information at frequent informal meetings in the lobby or at the coffee machine. (Perry et al., 1994) observed that developers in a particular organization spent up to 75 minutes per day in unplanned personal interaction. Sometimes, development teams share the same office area on purpose, to stimulate interaction and speed things up. A shared room is also one of the distinguishing practices of agile development.
These mechanisms all disappear when work is distributed. The challenges that face global software development all have to do with distance: temporal distance, geographical distance, and sociocultural distance. Along a second dimension, the challenges of global software development can also be classified in three categories (Ågerfalk et al., 2006):
communication and collaboration between team members: Individual team members need to exchange information and work together.
coordination between tasks: The work to be done at different sites needs to be coordinated.
control of the work: Management must keep in control of the work done at different sites.
Table 20.1 lists the main challenges according to this two-dimensional classification. Below, we discuss each of the entries in this table. Note that many of the issues discussed are interrelated; the borders between entries are not that clear-cut.
Table 20.1. Challenges of global system development (based on (Ågerfalk et al., 2006); (Clerc et al., 2007))
Temporal | Distance Geographical | Sociocultural | |
|---|---|---|---|
Communication | Effective communication | Effective information exchange Build a team | Cultural misunderstandings |
Coordination | Coordination costs | Task awareness Sense of urgency | Effective cooperation |
Control | Delays | Accurate status information Uniform process | Quality and expertise |
Effective communication When team members are at different locations, communication means are often asynchronous (email, for example). Asynchronous communication is less effective than synchronous communication. It is not possible to get an immediate clarification if a message is not understood. Problems may crop up at a later stage because people take the risk of not contacting a colleague at a remote site, but guess an answer and tacitly accept the risks.
Coordination costs For global software development projects, coordination costs are often larger than for collocated projects. In some cases, representatives from the client organization are located at a development site for the duration of the project. Key people such as managers and architects frequently travel to the different teams to have onsite meetings. The infrastructure tends to be more expensive too, in terms of bandwidth, videoconferencing hardware and software, and so on.
Delays When an issue arises that requires information from another site, it often incurs a delay. One may have to wait for the next teleconference meeting, send an email and wait for the other side to react, and so on. Asynchronous communication easily leads to delays where the same issue in a collocated team would be dealt with immediately simply by walking down the corridor and engaging in a discussion with the person involved.
For example, suppose a change request only touches upon the code base owned by a local site. Any problems a developer may have in handling this request can be solved by consulting a nearby colleague. If on the other hand a change request is multi-site, a developer at one site may have to communicate with a colleague at another site. If he knows which person to contact, he can send him an email and wait for a reply. If not, he first has to find out which person to contact. Initiating contact in a global project is even more difficult if more than two people are involved. Either way, delays are incurred.
Effective information exchange When teams are at geographically different sites, there is less informal, unplanned contact. During unplanned meetings at the coffee machine, highly valuable and relevant information is exchanged. Small issues that are easily settled in an unplanned meeting in the hall by a collocated team may have to be 'saved' until the next formal teleconference meeting in a global setting. Chances are then that a number of these smaller issues remain unresolved for a long time or are forgotten altogether. Unplanned social meetings also help people build up an awareness of what is important and what is not, and what the future of the project will bring. These issues are often largest at the start of a project, simply because one doesn't yet know team members at the other sites.
Effective information exchange is especially important during the early stages of a project. Damian and Zowghi (2003) report difficulties in handling requirements in a global software development environment. An often-used medium for exchanging such information is email. But email is a poor medium in which to handle ambiguities and may lead to lengthy discussions without actually resolving the issue. Emails raising a difficult requirements issue may not be answered immediately and end up in a stack, ultimately to be forgotten.
In a global setting, partners in information exchange often speak a different native language. It then becomes more difficult to exchange requirements unambiguously. It may be difficult to find the proper terms for domain entities. Income tax laws in my country make use of very special regulations that are difficult to express at all, let alone unambiguously. Partners in another country will have difficulties in interpreting them properly; they may use their background knowledge of their own tax rules to infer a likely meaning. In such circumstances, it may take a long time before problems related to misunderstood requirements come to the surface.
Individual members of a global team often have difficulties identifying appropriate expertise at other sites. As a consequence, they do not know whom to contact with a specific information request. (Fussell et al., 1998) identify four types of awareness problem in distributed teams:
activity awareness: what are the others doing?
availability awareness: when can I reach them?
process awareness: what are they doing?
perspective awareness: what are they thinking and why?
Ehrlich and Chang (2006) found that people communicate more frequently with someone else if they know what this person is working on, when they know this person from a previous project, or have some general idea about his knowledge and expertise. This suggests that improving awareness and familiarity of other team members in a global team helps. This and other studies also found that team boundaries are often permeable. People do not only rely on information from their immediate colleagues in the development team. They have a personal network that they rely upon, especially for technical matters.
In collocated teams, inadequate knowledge management is often compensated for by personal contact and knowing who knows what. Distributed teams need more thorough means of knowledge management. Local meetings may result in decisions that are not properly captured and disseminated to the other teams that need to know about them. The latter then have to guess things or rediscover them.
Build a team Building a team in a global development project is hampered because of the temporal and geographical distance. As a result, there is a higher chance of mismatches in terminology and definitions, resulting in communication overhead and delays.
Collocated teams tend to be more cohesive than global teams because of their daily interaction, physical proximity, similar background, and so on. In a global setting, team members from different sites may consider themselves as part of different teams rather than one global team. Such feelings may lead to a 'them and us' attitude between teams at different sites. This attitude is more likely to occur when the teams have different roles, such as a designer team at one site and a development team at another. This may result in negative attitudes and conflicts. Weak ties between team members impede the transfer of complex knowledge (Hansen, 1999). Usually, the knowledge that needs to be exchanged between sites of a distributed software development project is quite complex in nature. It would thus help to strengthen ties in a distributed software development project.
An issue closely related to team building is trust. Distance makes it difficult to build up relationships in which there is mutual trust. During the early phases, when requirements are being negotiated, trust is essential. Parties in this negotiating process may leave certain issues deliberately open or ambiguous. They may have a hidden agenda. Developers may keep things hidden from their manager to protect their position. Conversely, a manager may hide information from the developers so as not to alarm them at an early stage, and so on. In a collocated development team, many issues are resolved in open meetings. In a global setting, there is ample room for bilateral contact through emails, phone calls, and so on. Information then is spread to some people and not to others, possibly adding to the level of distrust. Distrust is further increased if emails are used as a weapon, for instance by copying management each time a problem is reported to a colleague.
If sites in a global project do not see themselves as partners, it may result in 'uncharitable' behavior (Herbsleb and Grinter, 1999). For instance, a person at one site might say that a certain change cannot be made. The recipient of this message at the other site may construe this as meaning that that person is not willing to make the effort.
People may feel that multi-site development is a first step towards reducing jobs. They will then not be inclined to communicate freely. If they do, their knowledge may be transferred to others, and they become easier to replace.
Task awareness In a global setting, work assignments may not be understood properly. This may easily lead to long discussions that add up to delays. For example, the precise distribution of responsibilities between a development team and the integration test team may not be understood properly and lead to long discussions between the two. Unlike single-site projects, in globally distributed projects, the amount of discussion generally does not decrease in the course of the project.
Team members do not only coordinate work through an input–process–output model. There is more to coordination of work than the formal exchange of messages. A team builds up a shared mental model of the work to be done. Team members have to know what is to be done, what the other team members know, and the goals of colleagues. By studying what designers do, (Curtis et al., 1988) found that performance is improved when team members have a shared mental model. Building such a shared model is a lot easier when the team is collocated.
Sense of urgency Multi-site development may result in differences in the perceived sense of urgency of handling requests. For example, a developer at one site may ask for clarification of some requirement in an email to a colleague at another site. The person receiving the email may not read his email for a while, or postpone an immediate answer. The developer in turn may be sitting idle, waiting for a reply. Direct contact with colleagues at the same site makes it easier to convey the urgency of a help request. Asynchronous communication such as sending emails lowers the perceived sense of urgency. The lack of a sense of urgency induces delays.
Accurate status information In a global setting, it is difficult to exert effective control. For instance, if a team at one site exceeds its plan, that team can easily blame management at a remote site that 'has no idea of the complexity of our subsystem'.
Tracking status is essential in a global software development project. If code is developed at different sites and has to be integrated at a third site, management needs to have accurate status information. If the schedule slips at one development site, it will also slip at the integration site. If status information is inaccurate, it may easily give rise to feelings of frustration elsewhere.
Uniform process It is important to have a uniform process strategy. Having nonuniform processes introduces delays. For example, one site may have a dedicated team for integration testing, while integration testing may be the responsibility of each subsystem team at another site. The integration team needs assistance from developers when issues arise, and this is complicated when developers have to deal with different processes. At integration time, speed is paramount to quickly resolve bugs discovered.
Establishing a uniform process requires negotiation. It is part of establishing common ground between sites. It usually does not work to simply impose one site's process upon another. This creates 'them and us' feelings, as mentioned before, and inhibits mutual trust.
On the other hand, different sites are likely to use different tools and methods, because of history, culture, or other reasons. Management must be able to accommodate these differences. The manager has to become an orchestrator rather than a dictator.
Cultural misunderstandings There are different kinds of culture: corporate culture, technical culture, and national culture. Corporate culture has to do with the organization one works in. Some organizations for instance have an open communication culture, others communicate through formal channels only. Technical culture has to do with the development processes followed. Some organizations are much more concerned about the quality of products shipped than others. National culture has to do with differences between people from different parts of the world. In the words of Browning (1994):
American managers have a hamburger style of management. They start with sweet talk – the top of the hamburger bun. Then the criticism is slipped in – the meat. Finally, some encouraging words – the bottom bun. With the Germans, all one gets is the meat. With the Japanese, all one gets is the buns; one has to smell the meat.
Culture is one of the most important challenges to be addressed in global software development. People from different parts of the world exhibit cultural differences. This ranges from simple dress codes, such as wearing a tie or not, to issues of hierarchy and structure, sense of time, and communication style. Cultural differences also impact the ease with which certain types of software can be developed. Middleware and embedded software are relatively culture-neutral. Application software, for example an end-user application to handle mortgages, is more culture-specific and thus requires more careful communication.
Hofstede (1997) deals with cultural differences at the national level. His book is based on research done between 1967 and 1973 at IBM, long before the era of global software development. Many years later, it was found to be very useful for designing user interfaces, in particular websites. And now it is found to be useful in grasping cultural issues in global software development. Hofstede distinguishes five dimensions along which cultural differences can be observed:
power distance In a culture with high power distance, status, wealth, and similar factors determine one's hierarchical status. In a culture with low power distance, individuals are considered equal.
collectivism versus individualism In a collectivistic culture, individuals are part of a group to which they are loyal. In an individualistic culture, everyone looks after himself, and personal interests take priority over those of the group one belongs to.
femininity versus masculinity This dimension has to do with gender values, where the more masculine values are earnings, challenges, and recognition while the more feminine values are good working relationships, cooperation, and employment security.
uncertainty avoidance This dimension reflects how tolerant people are when placed in an unfamiliar or new situation. A high value indicates that the culture is based on strict rules and procedures to mitigate uncertainty. A low value indicates the culture is more flexible in handling uncertainty.
long-term versus short-term orientation Long-term orientation is characterized by values such as persistence in pursuing goals, observing order, thrift. Short-term orientation is characterized by protecting one's face, personal steadiness, respect for tradition.
Of these, power distance, collectivism versus individualism, and uncertainty avoidance have the strongest impact on global software development.
People from Asia value personal relationships within a team more than the task at hand. The North-American and European culture on the other hand is very task-oriented. In a cross-Pacific meeting, team members from Singapore and Thailand might first have some small talk and inform about family issues, while team members from North America skip the introductions and come to business right away. In other words, the Individualism Index (IDV) is higher for North-Americans and Europeans than it is for people from Asia.
People from different places also have a different power distance. This is relevant for hierarchical relations within teams. In Northern America and Europe, managers have to convince their team members and team members may argue with their manager's decisions. In Asia, people respect authority: the power distance is large. This might clash when people from different cultures get to work in the same team. An American manager may expect discussion and not get it; a manager from Asia may be surprised by the opposition he encounters from his American team members.
Finally, societies with a low value for uncertainty avoidance (UAI) have better mechanisms for coping with uncertainty. They can deal with agile approaches, ill-defined requirements documents, and so on. Cultures with a high value for UAI favor waterfall models, heavy processes, strict change control procedures. Latin America and Japan have a high UAI value, whereas North America and India have low UAI value. European scores are quite mixed.
Cultural differences thus impact global software development. It should be noted that most of the current insight is anecdotal and common sense. Hofstede's dimensions provide a way to categorize issues that play a role. The above statements about cultural differences between, say, Europe and Asia, are simplifications of reality. For instance, there are large regional differences within Europe. Though the power distance is low for most European countries, it is relatively high for Belgium and France (see (Hofstede, 1997)).
Effective cooperation Cooperation between team members from different cultures imposes problems: differences in vocabulary, a possible reluctance on either side to ask questions, differences in communication style, and so on. A team member one side, for instance, may prefer direct contact through a phone call or videoconference contact, while his colleague may prefer to send email.
In collocated projects, as well as multi-site projects, it is important to know 'who is who', to recognize individuals, and acknowledge their expertise. This is a lot easier when members are located at the same site. Once contact has been initiated, people are more willing to overcome cultural differences in order to communicate and cooperate effectively.
Quality and expertise It is difficult to assess the quality and expertise of remote partners. A CMM level 5 certificate in itself does not guarantee quality. What matters is the level of technical expertise, and this level is often difficult to assess from a distance.
Olson and Olson (2000) identified four concepts that are important for making distributed development succeed:
Common ground refers to the knowledge team members have in common, and that they are aware of. If you discuss part of a design with a close and knowledgeable colleague, mentioning the name of a particular design pattern might suffice, while a much longer explanation is used when explaining the same concept to a novice on the team. Non-verbal communication is taken into account as well, and may adjust our assumptions on the fly of what people know or understand. Common ground is established dynamically. This is much easier if the team is collocated.
Technology such as videoconferencing or other high bandwidth channels helps to establish common ground, but it remains a difficult issue. People prefer to contact a colleague from their own location, if there is one at the remote site. The more common ground people from different sites have, the easier communication is. For newly established teams, such common ground has to be developed, for instance through site visits.
It is better to do more frequent traveling at the beginning of the project, to build common ground. Travel can also be used to build liaisons. A person from site A who has traveled to site B is known to people at site B. Whenever they have questions regarding the work of site A, they are more likely to contact the person they know. One may even exploit this phenomenon and use it to build liaisons. For instance, that person may travel to site B regularly, to maintain and foster the mutual contacts.
Achieving common ground is also known as socialization. Socialization refers to the process by which one learns what behaviors are desirable, and which knowledge and skills are required to do one's job. The most obvious examples of socialization are the introduction of a new member to the team, and a kick-off meeting at the beginning of a global software development project. Socialization in global teams takes place both in face-to-face meetings, and through electronic media such as emails, teleconferencing, and so on. It is generally acknowledged that face-to-face meetings are essential. Since software development projects are usually quite long running, there may be a need to re-socialize (Oshri et al., 2007): the ties established at the kick-off meeting simply fade away over time.
Since global software development projects tend to have regular face-to-face meetings, it is natural to incorporate the socialization aspects into those meetings. It is good practice to reserve some time specifically for socialization purposes. Otherwise the meeting will be completely filled with urgent project matters such as requirements conflicts, change requests, planning of the next release, and so on. The social element that 'comes for free' in a collocated project has to be planned for in a global project. Another way of implementing socialization is to have experts travel around or have the project manager visit sites outside the regular schedule of the face-to-face meetings.
Interaction in global software development often follows a rhythm: intense meetings are scheduled at regular intervals and in between those intervals interaction is less intense (Maznevski and Chudoba, 2000). The intense meetings are used to discuss important aspects, make far-reaching decisions such as the global partitioning of a system, and build relationships. The intervals between intense meetings tend to be shorter at the beginning of the project. They can be wider apart once the tasks are known. The reason for having periodic intense meetings rather than letting the situation at hand determine whether such a meeting is appropriate is logistical. It is often not feasible to gather the project manager, lead architect, and end-user representative at short notice.
An extensive survey of outsourcing projects confirmed that intense interactions between sites is the most important success factor in such projects, more so than coordination tools, CMM level, and upfront investment in architectural modeling (Tiwana, 2004).
Coupling refers to the amount and extent of communication required in performing tasks. Collocated teams can communicate very effectively in informal ways. Ambiguities can easily be solved over a cup of coffee and are less likely to play a major role because of the common ground people share. Certain tasks, such as brainstorming over design issues, are very collaborative and difficult to handle in a distributed fashion. It is better to design the organization such that tasks that require much collaboration are done at the same spot. Tasks that require little interaction can be executed at different sites. So, programming or testing relatively independent subsystems can be done at different sites. Clear and unambiguous communication is of paramount importance in such circumstances, since there is likely to be less common ground between the sites.
If an organization has no culture of cooperation or sharing, it will have difficulty operating successfully in a global software development effort. The transition to a sharing and cooperating organization requires changing work habits, learning new tools, and so on. Incentives are needed to make employees change their habits and make them ready for collaboration. Collaboration readiness not only applies to individuals but also to the organization as a whole.
Finally, the technology has to be there. With the advent of the Web and the availability of advanced groupware tools, such as weblogs, wikis, and so on, this is less of an issue now than it was ten years ago. Global software development projects use these Internet technologies to support communication and collaboration in a variety of ways:
Project management tools, usually workflow-oriented, allow people to synchronize their work.
Web-enabled versions of familiar tools, such as those for requirements tracking, planning, budget, and so on help people to coordinate their work remotely. For example, (Lanubile et al., 2003) discusses a Web-based support system for distributed software inspections.
An infrastructure to automate builds and tests provides the ability to control them remotely (Spanjers et al., 2006).
Web-based project repositories, such as workspaces, store and share files intelligently between sites.
Real-time collaboration tools bridge the soft skills gap in distributed work.
Knowledge management technology finds information and people.
A lot of knowledge of a software development organization is kept in unstructured forms: FAQs, mailing lists, email repositories, bug reports, lists of open issues, and so on. Lightweight tools such as wikis, weblogs, and yellow pages are other examples of relatively unstructured repositories to share information in global projects. In the knowledge management literature, this strategy is known as the personalization strategy. Each person has his own way to structure the knowledge. The threshold for contribution is usually low, but the effort expended in finding useful information is higher. Another strategy is codification, where the knowledge is codified in a structured way that can be used while querying. An advantage of the codification strategy is that the information has the same form and structure. A disadvantage is the extra effort it takes to cast the information in the form required. A hybrid strategy may be used to have the best of both worlds (Desouza et al., 2006).
(Gao et al., 2002) describe PIMS, a Web-based problem information management system. PIMS not only provides Web-based access to support the various problem-reporting tasks, such as problem reporting, status tracking, and information search, but it also allows for customization. Different users of the system may configure their own workflow for handling problem reports, define their own report formats, and use their own data formats. Teams in a global software development project may thus employ their own local processes, yet communicate and coordinate their work through a shared system.
The mere availability of tools that support global development is not sufficient, though. Efficient use of these technologies also depends on properties of the organization (policies, rewards, incentives) and the degree to which people understand the technology (Orlikowski, 1992).
We may distinguish two types of communication media in global software development projects: simple media such as email messages and phone calls, and rich media such as teleconference meetings and site visits. In effective teams, form follows function (Maznevski and Chudoba, 2000): simple messages are handled by simple media, while complex messages are handled by rich media. In ineffective global teams, one may find lengthy discussions on somewhat irrelevant issues in a teleconference call, while essential decisions are communicated in a short email message.
It is important for an organization to capture the lessons learned to prevent future development projects making the same mistakes over and over again. Capturing the lessons learned is especially difficult in global software development projects because the knowledge is spread. The root cause of a certain performance problem may be a combination of decisions of a functional nature at one site and decisions about data storage at another.
One way to capture such lessons learned is through Communities of Practice (CoPs). A community of practice is a, usually informal, group of people who share certain knowledge. For instance, all software architects of an organization may form a community of practice. Such a community creates knowledge, shares it, may have regular meetings to discuss their field of expertise, and makes their knowledge accessible to others, for instance through a website. Many software development organizations have such communities of practice. They capture and foster the collective knowledge of the organization. Communities of practice often span boundaries: experts from different projects and different branches of the organization can be members of the same community.
There are two ways in which one may address the lack of informal communication in global software development projects:
reduce the need for informal communication, and
provide technologies that ease informal communication.
Usually, a combination of both is used.
Reducing the need or communication, be it formal or informal, is usually achieved through organizational means. Typically, people that have to interact a lot are located at the same site. This not only reduces the need for communication, but also makes the coordination of work a lot easier. For instance, experts in a certain area, such as user interfaces, are put together at the same site. User interfaces for all the systems of an enterprise are then developed at that site. Alternatively, the gross structure of the system, the architecture, can be used to divide work amongst sites. This can be seen as a variation of Conway's Law (Conway, 1968), which states that the structure of a product mirrors the organizational structure of the people who designed it. If three groups are involved in the development of a system, that system will have three major subsystems. This way of decomposing work is the programming-in-the-large equivalent of Parnas' advice to consider a module as a 'responsibility assignment rather than a subprogram' (Parnas, 1972). A third way is to split up tasks according to life cycle phases: design is done at one site, development at a second, testing at a third.
Each of these organizational means has advantages and disadvantages. Each may work well, but problems may arise if a lot of coordination is required that crosses the boundaries of the division. Many projects require more than one functional area. A system needs a user interface, a database, security protection, and so on. If each site has a specific expertise, many projects will require a lot of cross-site coordination. If different sites are responsible for different subsystems, problems may arise with tasks that involve more than one subsystem, such as integration testing. If different sites are responsible for different life cycle phases, this may incur delays. For instance, the development site may decide not to ship code to the testing site until all the components have been developed, and the site responsible for testing will have to wait for the code to be shipped.
Division of work amongst sites is not only guided by objective arguments. For instance, if different sites develop different components, a political battle may ensue as to who is going to develop which component. A component whose requirements are volatile, or one that critically depends on hardware that has not been acquired yet, may easily lead to problems and had thus better be the responsibility of someone else. On the other hand, a high-visibility component may be attractive to develop. This way, politics enters the picture when it comes to division of labor.
The three main ways of coordinating work in global software development are architecture, plans, and processes (Herbsleb and Grinter, 1999). The architecture of a system establishes a division of responsibilities into independent building blocks. The design and implementation of the building blocks may be assigned to different sites. Plans describe when milestones are reached and who does what. Processes describe how the software is going to be developed. All three are needed.
Global software development at first sight seems to better fit the more traditional development paradigms in which a lot of effort is spent at the beginning on delineating and documenting tasks. These tasks can then be assigned to different teams. Agile methods seem less fit for global software development, because of the need for very frequent communication and the onsite presence of a customer. Paasivara and Lassenius (2006) argue that many of the agile practices not only pose challenges for global system development, but can also be seen as benefits. Provided suitable tools for communication are in place, the frequent communication that is typical for agile projects may actually help communication in the project, foster team building, increase mutual awareness of people, and so on. Continuous integration and testing gives fast feedback, so that issues come to the front very quickly. Misunderstandings between teams thus have a better chance to surface quickly, before they become a big problem.
Global software development is orthogonal to outsourcing. Distributed teams may or may not be part of the same company. Most of the challenges are in essence independent of this distinction, but are likely to be larger in the case of outsourcing. In an outsourcing context, cultural differences tend to be larger, company policies might differ, and there is less background between the parties involved. This poses greater challenges for communication, coordination, and control. Partial answers to these greater challenges are dependencies (for example, all development is outsourced) and strict contractual agreements for controlling purposes.
Global software development poses a number of challenges that have to do with distance in time, place, and culture. These challenges concern the way people communicate and collaborate, and the way work is coordinated and controlled. The most striking challenges concern:
finding ways to deal with the lack of informal communication between team members, and
handling cultural differences.
Software developers in a collocated team exchange a lot of valuable information in informal and unplanned meetings. The information exchanged is tacit and becomes part of the shared knowledge of that group of developers. Such informal exchange is not possible in a global development project and this needs to be catered for in a different way: through regular site visits, teleconferencing, Web-based tools to share knowledge, and so on. Intense interaction between sites is the most important success factor in global software development projects (Tiwana, 2004).
Cultural differences also impact global software development. The main dimensions along which cultural differences affect global software development are:
power distance: Is a person's hierarchical status important or are individuals considered equal?
collectivism versus individualism: Are individuals part of a group or do personal interests take priority?
uncertainty avoidance: Is the culture flexible about uncertainty?
A number of techniques and tools are emerging to overcome the challenges of global software development. The International Conference on Global Software Engineering (ICGSE) is fully devoted to the topic. To paraphrase Brooks (1987): each of the many solutions proposed will contribute its mite. But we should not expect miracles. Distance still matters (Olson and Olson, 2000).
Case studies of global software development and the issues encountered are discussed by Damian and Zowghi (2003). (Herbsleb and Mockus, 2003) is an empirical study into delays induced by multi-site development. Further case studies are reported in (Herbsleb and Grinter, 1999), (Herbsleb et al., 2005), (Casey and Richardson, 2006), (Damian, 2007), and (DeLone et al., 2005). (Software, 2001) and (Software, 2006a) are special journal issues devoted to global software development. (Carmel, 1999) is a well-known textbook on global software development.
The 30 meter threshold for information exchange stems from (Allen, 1977). Different coordination mechanisms for distributed development are discussed in (Grinter et al., 1999). Herbsleb (2007) provides a concise overview of the state of the art. (Desouza et al., 2006) discuss knowledge management in global software development.
Critical success factors of multi-site development are discussed in (Olson and Olson, 2000). (Ramasubbu et al., 2005) translate these success factors into a process maturity framework to deal with distributed development. (Hofstede, 1997) is the seminal text on cultural differences amongst organizations. Cultural issues in software development are given special attention in (Krishna et al., 2004) and (Borchers, 2003).
What is global software development?
In what ways does global software development incur delays?
What makes team building more difficult in global software development?
Discuss Hofstede's cultural dimensions and how they apply to distributed software development.
Why is common ground important in software development?
Explain how Conway's Law relates to global software development.
[35] Outsourcing means that work is done by a third party. Offshoring means that it is done in a different country from the contracting organization.