Abstract Prior research documents how the use of national cultural differences when used as an argument for failed collaboration is problematic and makes information technology (IT) companies blind to the challenges in global software development (GSD). Nevertheless, we still witness how issues in GSD work are kept explained, applied, and predicted through generic descriptions of national cultural behavior. Based on two ethnographic studies conducted within two large Danish IT companies, we extend prior work on implicit bias. The paper presents empirical examples on the widespread practice of using racist and stereotypical rhetoric in GSD, which initially motivated us to look for alternative strategies for analyzing the actual and locally situated collaboration‐related problems within organizations involved in GSD. Our contributions are threefold: (1) We show how the widespread practice of using negative stereotypical rhetoric is weaved into the fabric of GSD engagements; (2) we present the empirical results of attending to implicit bias as an approach to explore and combat pervasive practices that deploy static cultural narratives and stereotypes in GSD; and (3) we propose three areas in GSD that software organizations should investigate to identify and address the implicit biases that potentially challenge or shatter their distributed collaborative work.

Despite the prevalence of global software Engineering (GSE), many companies continuously struggle to collaborate across geographical distance, nationalities, and languages. Prior research documents how the use of national cultural differences as an argument for failed collaboration is common amongst people working in GSE, which has made IT companies blind to the fundamental challenges of GSE work emerging upon the conditions for the actual conduct of work and practices undertaken by human actors. Based on an interventionist ethnographic study conducted within a Danish IT company, we present the results of attending to implicit bias as an approach to combat pervasive practices that deploy static cultural narratives and negative stereotypes in GSE. We find that implicit bias is a useful grip for moving discussions beyond negative cultural rhetoric and to reconsider the actual and locally situated collaboration-related problems that exist within organizations involved in GSE.

Using ethnographic data, we provide a critical reflection on the discrepancies between the application of agile development principles and the conditions which render these principles effective for global software development work. This reflection is based on the analysis of a failed collaboration within a global software project, which relied heavily on feedback from mundane project tools utilized for everyday coordination and monitoring. Our study reveals that these tools hid serious issues relating to both the distribution of socio-technical skills and a discharge of accountability in task execution. As a result, markers of complex collaborative problems were concealed. Furthermore, the imbalance evident in outsourcing setups, which is enacted through high and low status task distribution among partners, further compounds collaboration problems by emphasizing assumptions about remote workers in the absence of direct forms of knowledge interchange.

We report on an ethnographic study of an outsourcing global software development (GSD) setup between a Danish IT company and an Indian IT vendor developing a system to replace a legacy system for social services administration in Denmark. Physical distance and GSD collaboration issues tend to be obvious explanations for why GSD tasks fail to reach completion; however, we account for the difficulties within the technical nature of the software system task. We use the framework of information infrastructure to show how replacing a legacy system in governmental information infrastructures includes the work of tracing back to knowledge concerning law, technical specifications, as well as how information infrastructures have dynamically evolved over time. Not easily carried out in a GSD setup is the work around technical tasks that requires careful examination of mundane technical aspects, standards, and bureaucratic forms, as well as the excavation work that keeps the information infrastructure afloat.

We report on an ethnographic study of an outsourcing global software development (GSD) setup between an Indian IT vendor and an IT development division of a Danish bank. We investigate how the local IT development work is shaped by the global setup in GSD and argue that the bank had cultural blind spots toward the changes in Denmark. Three critical issues were neglected due to the cultural blind spots: 1) increased number of interruptions, 2) lack of translucence of remote colleagues' work, and 3) the re-definition of boundaries between work and articulation work. The implications of these findings include considerations for how to organize GSD practices and prepare the organizational changes that occur when moving from a co-located software development organization to an inter-organizational geographically distributed organization. Also, our findings open up discussions about the professional identity of IT developers within GSD, including extending the qualifications for IT developers.

Does distance still matter? Reporting on a comparative analysis of four ethnographic studies of global software development, this article analyzes the fundamental aspects of distance as depicted in the famous paper “Distance Matters.” The results suggest that, although while common ground, collaboration readiness, and organizational management are still important aspects for distributed collaboration, the arguments concerning coupling of work and collaboration technology readiness need to be refined. We argue that in working remotely, closely coupled work tasks encourage remote workers to spend the extra effort required in articulation of work to make the collaboration function. Also we find that people in distributed software development have already made collaborative technologies part of their work, and individuals are comfortable with them; thus, collaboration technology readiness takes a different shape in this setting.