Before the loss of teamness as a centrifugal force of global software teams is covered, the characteristics of a team must be presented. Carmel state that a real team must satisfy the following characteristics [29]:
A real team:
• is perceived to be a team by its members
• is recognized as a team by non-members
• has collective responsibility for its products
• shares responsibility for managing its work
• has a common goal or set of tasks
• works together on tasks that are interdependent
• demands peak performance from all members
• shares its rewards
• is small in number of members
It is clear from the presented characteristics that in good teams, team members help and complement each other and know the other team members well. In such team there is also high cohesion which leads to enhanced motivation, enhanced moral, greater productivity, harder work, more open communication and higher job-satisfaction [29]. The loss of team- ness which occurs in global software teams, is a consequence of distance between team members, cultural differences and the loss of communication richness. Due to this loss of teamness global software teams satisfy less of these properties than collocated teams.
Loss of teamness
Loss of cohesion
One of the most important factors for a successful software development team is cohesion. Teams with high cohesion have many benefits as mentioned before. However, cohesion is more difficult for cross-cultural teams because of physical separation and lack of informal contact [29, 72, 70]. Due to these restrictions, team members may not be aware of the details of the work activities of their other team members, because they are only interested in their own activities. If awareness of current work is not completely spread across the whole team, misunderstandings can continue unnoticed and code conflicts can arise [4]. At the same time this lack of familiarity with remotely located colleagues can result in a lack of teamness and a reduced sense of trust [3].
Reduced trust
In a globally distributed setting trust is far harder to acquire or maintain than in classical development, because of the lack of close interpersonal contact [123, 105]. Pyysi¨ainen defines six problem areas in trust building, namely [123]:
• Personal dispositions
Personalities and interaction styles of parties in different companies can be ambigu- ous. It is possible that receivers interpreted a short and direct message, which was sent by a person who preferred messages that went straight to the point, as a commanding message and that the sender was not satisfied with their work. This misunderstanding is a consequence of different personal ways of expressing themselves; this could lead to misunderstandings and can reduce the level of trust.
• Common history
Because of the temporary nature of software development teams, companies often forgot to discuss the available documentation and whom to contact in specific issues. As a consequence of the lack of information and the fact that clear organizational charts and face-to-face meetings were lacking, background information was not suf- ficient exchanged. People did not get to know the roles, responsibilities and skills of each other and hesitated to spontaneously give and ask for help. This lack of knowl- edge can led to a decreased level of trust and motivation.
• Mediating third parties
In the case of distributed development spontaneous transfer of knowledge via third parties was often blocked, because no mediating link persons between companies were available. The two companies did not know the exact reasons for delay in deliv- eries and testing, they did not know the causes for changes and some troubling bugs remained unclear. This kind of uncertainty about the positive intentions and motives of the other party can result in distrust.
• Shared category membership
One obvious problem is that people from different companies not actually feel that they are working towards a common goal. Reaching the sub-goals of each site seems
4. THE CHALLENGES OFGLOBALSOFTWARE DEVELOPMENT
to have the highest priority instead of reaching the common goal. A lot uncertainty exist whether information is confidential and must be withheld from other companies or that the information is free accessible for other companies. When an employee is in doubt, the information is kept internal and is not accessible by the other companies. In this case ideas that would have helped the progress of the project are not exchanged. Another reason why it is difficult for a single site to identify them with a common goal is the limited feedback they receive on the quality of their work and that they could not perceive how their contributions are affecting the total progress. As a consequence, the commitment of the subcontractor can be weakened or even totally collapsed.
• Predictable role behavior
Co-located organizations often indicate roles in their processes but when an organi- zation is operating in a global setting these clear prediction of the behavior of other people on the basis of their role is not possible because there was no such indication for the global organization. As a consequence it is hard to determine who has the right to decide on issues, especially at lower levels in the organization. It is even possible that a developer makes major changes to core modules, even though those kinds of tasks were not ascribed to him. These uncertainties have a negative influence of the level of trust between colleagues.
• Internalized common rules
It is often the case that basic issues as common terms are not clearly stated. There is also a lack of binding principles, communication and change-request protocols to be used in the development process. These unclear thresholds for changes can cause unnecessary and overlapping changes, contributes to uncertainties and reduces the level of trust between the different sites.
Due to the lack of close interpersonal contact and the problems in building trust, colleagues in a distributed setting are less inclined to help remote colleagues when workloads are heavy [73]. As a consequence developers may be doubtful of the knowledge, capabilities and skills of the team members from other sites [11, 131]. This impression may have a significant influence on the collaboration in a team.
Perceived threat from low-cost alternatives
Employees in the higher-cost economies can have the feeling that their jobs are most likely to be taken by their colleagues in lower-cost economies, creating a ”we versus they” men- tality [50, 74, 32]. As a result, they may not want to cooperate with their remote colleagues, which negatively affect the team work.
Increased Team size
Global teams in multiple sites are generally larger per task than co-located teams [29]. When a team becomes larger there are more employees involved which al have another role in the development process, this makes it more difficult for a manager to control the project
Cultural differences
[53]. The main advantage of small teams is that it ensures effective communication among all team members [26]. This can also result in the increased level of trust and cohesiveness between team members. When a team becomes larger these advantages disappear and the success rate of the project drops down sharply [29, 26].