Empirical Evidence in Global Software

Engineering: A Systematic Review

Recognized as one of the trends of the 21st century, globalization of the world economies brought significant changes to nearly all industries, and in particular it includes software development. Many companies started global software engineering (GSE) to benefit from cheaper, faster and better development of software systems, products and services. However, empirical studies indicate that achieving these benefits is not an easy task. Here, we report our findings from investigating empirical evidence in GSE-related research literature. By conducting a systematic review we observe that the GSE field is still immature. The amount of empirical studies is relatively small. The majority of the studies represent problem-oriented reports focusing on different aspects of GSE management rather than in-depth analysis of solutions for example in terms of useful practices or techniques. Companies are still driven by cost reduction strategies, and at the same time, the most frequently discussed recommendations indicate a necessity of investments in travelling and socialization. Thus, at the same time as development goes global there is an ambition to minimize geographical, temporal and cultural separation. These are normally integral parts of cross-border collaboration. In summary, the systematic review results in several descriptive classifications of the papers on empirical studies in GSE and also reports on some best practices identified from literature.

                            The concept of global software engineering (GSE) originates from contract programming, which was a form of outsourcing known from the 1970s (Lee et al. 2000). In contrast to outsourcing, GSE addresses software engineering activities performed by globally distributed teams. Software development became global in the 1990s as a consequence of the PC revolution (Carmel 1999) and sequential problems of tight budgets, shortage of resources and time motivated many companies to start looking for partners or to set up development sites in different countries. As an outcome of this evolution, many companies built joint

ventures and relocated their development centers to low-cost countries. However, soon practitioners started

to realize that globally distributed development, in particular from a project management perspective, is

considerably more challenging than even the most complex project managed entirely in house (Karolak

1998). Therefore, empirical research results are needed to help understand the challenges with the aim of

helping practitioners to improve performance of global software teams. This demand for empirical results is

growing as a consequence of an increasing number of internationally distributed software organizations.

Continuous Coordination: A New Paradigm to Support Globally Distributed Software Development Projects

Along with the rapid globalization of companies, the globalization of software development has become a reality. Many software projects are now distributed in diverse sites across the globe. The distance between these sites creates several problems that did not exist for previously collocated teams. Problems with the coordination of the activities, as well as with the communication between team members, emerge. Many collaborative software engineering tools that have been used to date, in global software development projects, exhibit a fundamental paradox: they are meant to support the collaborative activity of software development, but cause individuals and groups to work more or less independently from one another. The underlying issue is that existing software engineering tools, such as configuration management repositories, issue trackers, and workflow engines, separate time and tasks in concrete but isolated process steps. Designing tools based on the premise that human activities can be codified and that periodic re synchronization of tasks is an easy step reflects poor understand-ing human nature. We therefore propose a new approach to supporting collaborative work called Continuous Coordination. Underlying Continuous Coordination is the premise that humans must not and cannot have their method of collaboration rigidly dictated, but should be supported flexibly with both the tools and the information to coordinate their activities and to collaborate in their activities as they see fit. In this paper, we define the concept of Continuous Coordination, introduce our work to date in building prototypes that support the Continuous Coordination paradigm in the context of Global Software Development, and set out a further research agenda to be pursued.

The Geography of Coordination

Geographically distributed development creates new questions about how to coordinate multi-site work. In this paper, we present four methods product development organizations used to coordinate their work: functional areas of expertise, product structure, process steps, and customization. We describe the benefits and difficulties with each model. Finally, we discuss two difficulties that occur irrespective of the model used: consequences of unequal distribution of project mass, and finding expertise.

              Frequent ad hoc communication, however, is only one way that individuals can coordinate their work. Other approaches focus on designing the organization and assigning the work so as to reduce the amount of informal communication required. Although this will not eliminate the need for informal communication, the goal is to reduce it to a more manageable level. In this section, we introduce four models that organizations may adopt for this purpose. The first comes from the observation that a particular function is generally carried out by people with similar expertise. Second model of organizing focuses on projects, placing all work necessary to produce a product release in one organizational unit. In addition to these models, at least two other bases have been suggested for designing R&D organizations: product structure and development processes.

Building the Team: Tasks, People, and Relationships

The first rule of teamwork at SEI, the money management firm headquartered in Oaks, Pennsylvania, is that there are remarkably few rules. Teams have anywhere from 2 to 30 members and every team is structured differently. Most employees belong to one “base team” as well as three or four ad hoc teams. These ad hoc teams give SEI a sense of perpetual motion. Work is distributed among roughly 140 self-managing teams. Some are permanent, designed to serve big customers or important markets. But many are temporary: People come together to solve a problem and disband when their work is done. The result is a workplace that is always on the move. “We call it fluid leadership,” says SEI's Chairman and CEO Al West. “People figure out what they're good at, and that shapes what their roles are. There's not just one leader.

We have focused on some of the important dimensions of creating and managing teams in a direct fashion. Much planning needs to precede the construction of teams and, once constructed, teams need fairly continuous maintenance. To the extent that the teams are manager-led, this work is the purview of the leader or manager; the more self-directing the team becomes, the more the team will do this for itself. When the team is built—in terms of the task, the people, and their relationships—the leader's work does not stop. During this time, the leader needs to also assess the physical, material, economic, and staffing resources necessary for performing the work to be done. The focus of the leader should not be to presume that everything is fine, but rather to coach the team to work through the issues of task, people, and relationships systematically.

Building the Team: Tasks, People, and Relationships

The first rule of teamwork at SEI, the money management firm headquartered in Oaks, Pennsylvania, is that there are remarkably few rules. Teams have anywhere from 2 to 30 members and every team is structured differently. Most employees belong to one “base team” as well as three or four ad hoc teams. These ad hoc teams give SEI a sense of perpetual motion. Work is distributed among roughly 140 self-managing teams. Some are permanent, designed to serve big customers or important markets. But many are temporary: People come together to solve a problem and disband when their work is done. The result is a workplace that is always on the move. “We call it fluid leadership,” says SEI's Chairman and CEO Al West. “People figure out what they're good at, and that shapes what their roles are. There's not just one leader.

The Task: What Work Needs to Be Done?

What practices and structures need to be put into place to achieve highly functioning teams? To a great extent, this is determined by the nature of the work that groups are doing. For example, some teams make products, some teams provide services, other teams make decisions, and still others provide advice and consultation. The nature of the work sets constraints on design. However, there is much variation in team design, even among companies doing very similar types of work—and sometimes even large variation among teams within the same company.

The People: Who Is Ideally Suited to Do the Work?

What manager has not wrestled with the question of who to put on the team? As illogical as it may sound, many managers form their team without too much thought and subsequently, attempt to figure out how to capitalize upon and match up people's skills. A much better approach is to carefully think about the task in terms of the work to be done, and then choose people on the basis of their skills relevant to that work. For example, think back to the three basic purposes of teamwork described earlier: Tactical, problem-solving, and creative. Obviously, creative types are not as well suited for tactical teams as are highly organized, results-driven people, and vice versa.

 

Relationships: How Do Team Members Socialize Each Other?

Someone could get the idea from reading this chapter that teams are built from scratch and that, once built, the manager's work is largely done. This assertion, of course, is false. Teams are not built from scratch; instead, a member or two is added to a team that is changing its direction; members leave teams for natural (and other) reasons. In short, members of teams are continuously entering and exiting; as a consequence, the team itself is constantly forming and reconfiguring itself. Group socialization is the process of how individuals enter into and then (at some point) leave teams. The process is disruptive, to be sure, yet it need not be traumatic or ill-advised.

When people begin to work together as a team, they immediately begin a process of socialization, such that members of the team mutually shape each other's behavior. More often, teams may undergo changes in membership, such that some members may leave and new ones may enter. The process of socialization is essential for the ability of team members to work together and coordinate their efforts.

Conclusions

We have focused on some of the important dimensions of creating and managing teams in a direct fashion. Much planning needs to precede the construction of teams and, once constructed, teams need fairly continuous maintenance. To the extent that the teams are manager-led, this work is the purview of the leader or manager; the more self-directing the team becomes, the more the team will do this for itself. When the team is built—in terms of the task, the people, and their relationships—the leader's work does not stop. During this time, the leader needs to also assess the physical, material, economic, and staffing resources necessary for performing the work to be done. The focus of the leader should not be to presume that everything is fine, but rather to coach the team to work through the issues of task, people, and relationships systematically.