Understanding agile software development practices using shared mental models theory

ContextAgile software development is an alternative software development methodology that originated from practice to encourage collaboration between developers and users, to leverage rapid development cycles, and to respond to changes in a dynamic environment. Although agile practices are widely used in organizations, academics call for more theoretical research to understand the value of agile software development methodologies.ObjectiveThis study uses shared mental models theory as a lens to examine practices from agile software methodologies to understand how agile practices enable software development teams to work together to complete tasks and work together effectively as a team.MethodA conceptual analysis of specific agile practices was conducted using the lens of shared mental models theory. Three agile practices from Xtreme Programming and Scrum are examined in detail, system metaphor, stand-up meeting, and on-site customer, using shared mental models theory.ResultsExamining agile practices using shared mental models theory elucidates how agile practices improve collaboration during the software development process. The results explain how agile practices contribute toward a shared understanding and enhanced collaboration within the software development team.ConclusionsThis conceptual analysis demonstrates the value of agile practices in developing shared mental models (i.e. shared understanding) among developers and customers in software development teams. Some agile practices are useful in developing a shared understanding about the tasks to be completed, while other agile practices create shared mental models about team processes and team interactions. To elicit the desired outcomes of agile software development methods, software development teams should consider whether or not agile practices are used in a manner that enhances the team’s shared understanding. Using three specific agile practices as examples, this research demonstrates how theory, such as shared mental models theory, can enhance our understanding regarding how agile practices are useful in enhancing collaboration in the workplace.     

Individual empowerment of agile and non-agile software developers in small teams

ContextEmpowerment of employees at work has been known to have a positive impact on job motivation and satisfaction. Software development is a field of knowledge work wherein one should also expect to see these effects, and the idea of empowerment has become particularly visible in agile methodologies, in which proponents emphasise team empowerment and individual control of the work activities as a central concern.ObjectiveThis research aims to get a better understanding of how empowerment is enabled in software development teams, both agile and non-agile, to identify differences in empowering practices and levels of individual empowerment.MethodTwenty-five interviews with agile and non-agile developers from Norway and Canada on decision making and empowerment are analysed. The analysis is conducted using a conceptual model with categories for involvement, structural empowerment and psychological empowerment.ResultsBoth kinds of development organisations are highly empowered and they are similar in most aspects relating to empowerment. However, there is a distinction in the sense that agile developers have more possibilities to select work tasks and influence the priorities in a development project due to team empowerment. Agile developers seem to put a higher emphasis on the value of information in decision making, and have more prescribed activities to enable low-cost information flow. More power is obtained through the achievement of managing roles for the non-agile developers who show interest and are rich in initiatives.ConclusionAgile developers have a higher sense of being able to impact the organisation than non-agile developers and have information channels that is significantly differently from non-agile developers. For non-agile teams, higher empowerment can be obtained by systematically applying low-cost participative decision making practices in the manager–developer relation and among peer developers. For agile teams, it is essential to more rigorously follow the empowering practices already established.     

Global software testing under deadline pressure: Vendor-side experiences

ContextIn the era of globally-distributed software engineering, the practice of global software testing (GST) has witnessed increasing adoption. Although there have been ethnographic studies of the development aspects of global software engineering, there have been fewer studies of GST, which, to succeed, can require dealing with unique challenges.ObjectiveTo address this limitation of existing studies, we conducted, and in this paper, report the findings of, a study of a vendor organization involved in one kind of GST practice: outsourced, offshored software testing.MethodWe conducted an ethnographically-informed study of three vendor-side testing teams over a period of 2 months. We used methods, such as interviews and participant observations, to collect the data and the thematic-analysis approach to analyze the data.FindingsOur findings describe how the participant test engineers perceive software testing and deadline pressures, the challenges that they encounter, and the strategies that they use for coping with the challenges. The findings reveal several interesting insights. First, motivation and appreciation play an important role for our participants in ensuring that high-quality testing is performed. Second, intermediate onshore teams increase the degree of pressure experienced by the participant test engineers. Third, vendor team participants perceive productivity differently from their client teams, which results in unproductive-productivity experiences. Lastly, participants encounter quality-dilemma situations for various reasons.ConclusionThe study findings suggest the need for (1) appreciating test engineers’ efforts, (2) investigating the team structure’s influence on pressure and the GST practice, (3) understanding culture’s influence on other aspects of GST, and (4) identifying and addressing quality-dilemma situations.     

The effect of process tailoring on software project performance: The role of team absorptive capacity and its knowledge‐based enablers

Software process tailoring (SPT) is a team‐based and learning‐intensive activity that addresses the particular dynamic characteristics of a development project. Because SPT critically influences how projects are conducted, its performance should be investigated. However, the extant literature lacks empirical evidence on how the underlying effects of SPT performance and its team‐supportive factors operate and influence software project performance. From the knowledge perspective, this study adopts dynamic capabilities theory and considers the learning ability and absorptive capacity of software project teams to develop a theoretical model to address this gap. The results of an empirical examination of the model with 135 software project teams advance our understanding of how team‐level learning antecedents—experience, communication quality and trust—dynamically facilitate teams' absorptive capacity (AC) when they conduct SPT, which in turn reinforces project performance. The mediating effects of the proposed model are unveiled and discussed, and theoretical implications as well as practical guidance for how AC and these factors promote SPT and project performance are suggested.     

Understanding the attitudes,knowledge sharing behaviors and task performance of core developers: A longitudinal study

ContextPrior research has established that a few individuals generally dominate project communication and source code changes during software development. Moreover, this pattern has been found to exist irrespective of task assignments at project initiation.ObjectiveWhile this phenomenon has been noted, prior research has not sought to understand these dominant individuals. Previous work considering the effect of team structures on team performance has found that core communicators are the gatekeepers of their teams’ knowledge, and the performance of these members was correlated with their teams’ success. Building on this work, we have employed a longitudinal approach to study the way core developers’ attitudes, knowledge sharing behaviors and task performance change over the course of their project, based on the analysis of repository data.MethodWe first used social network analysis (SNA) and standard statistical analysis techniques to identify and select artifacts from ten different software development teams. These procedures were also used to select central practitioners among these teams. We then applied psycholinguistic analysis and directed content analysis (CA) techniques to interpret the content of these practitioners’ messages. Finally, we inspected these core developers’ activities as recorded in system change logs at various points in time during systems’ development.ResultsAmong our findings, we observe that core developers’ attitudes and knowledge sharing behaviors were linked to their involvement in actual software development and the demands of their wider project teams. However, core developers appeared to naturally possess high levels of insightful characteristics, which became evident very early during teamwork.ConclusionsProject performance would likely benefit from strategies aimed at surrounding core developers with other competent communicators. Core developers should also be supported by a wider team who are willing to ask questions and challenge their ideas. Finally, the availability of adequate communication channels would help with maintaining positive team climate, and this is likely to mitigate the negative effects of distance during distributed developments.     

A teamwork model for understanding an agile team: A case study of a Scrum project

ContextSoftware development depends significantly on team performance, as does any process that involves human interaction.ObjectiveMost current development methods argue that teams should self-manage. Our objective is thus to provide a better understanding of the nature of self-managing agile teams, and the teamwork challenges that arise when introducing such teams.MethodWe conducted extensive fieldwork for 9 months in a software development company that introduced Scrum. We focused on the human sensemaking, on how mechanisms of teamwork were understood by the people involved.ResultsWe describe a project through Dickinson and McIntyre’s teamwork model, focusing on the interrelations between essential teamwork components. Problems with team orientation, team leadership and coordination in addition to highly specialized skills and corresponding division of work were important barriers for achieving team effectiveness.ConclusionTransitioning from individual work to self-managing teams requires a reorientation not only by developers but also by management. This transition takes time and resources, but should not be neglected. In addition to Dickinson and McIntyre’s teamwork components, we found trust and shared mental models to be of fundamental importance.     

Perceived barriers to effective knowledge sharing in agile software teams

While the literature offers several frameworks that explain barriers to knowledge sharing within software development teams, little is known about differences in how team members perceive these barriers. Based on an in‐depth multi‐case study of four software projects, we investigate how project managers, developers, testers and user representatives think about barriers to effective knowledge sharing in agile development. Adapting comparative causal mapping, we constructed causal maps for each of the four roles and identified overlap and divergence in map constructs and causal linkages. The results indicate that despite certain similarities, the four roles differ in how they perceive and emphasize knowledge‐sharing barriers. The project managers put primary emphasis on project setting barriers, while the primary concern of developers, testers and user representatives were project communication, project organization and team capabilities barriers, respectively. Integrating the four causal maps and the agile literature, we propose a conceptual framework with seven types of knowledge‐sharing barriers and 37 specific barriers. We argue that to bridge communication gaps and create shared understanding in software teams, it is critical to take the revealed concerns of different roles into account. We conclude by discussing our findings in relation to knowledge sharing in agile teams and software teams more generally.     

A theory of distances in software engineering

ContextCoordinating a software project across distances is challenging. Even without geographical and time zone distances, other distances within a project can cause communication gaps. For example, organisational and cognitive distances between product owners and development-near roles such as developers and testers can lead to differences in understanding and interpretation of the business requirements. Applying good software development practices, known to enhance alignment and coordination within development projects, can alleviate these challenges.ObjectiveThe aim of our research is to identify and describe underlying factors which can explain why certain practices support aligning and coordinating software development projects.MethodWe have inductively generated a theory analysing empirical data consisting of 15 interviews from 5 different companies. The systematic and iterative analysis was based on an initial hypothesis that distances affect development, and on results from previous research.ResultsWe present a theory of distances that explains how practices improve the communication within a project by impacting distances between people, activities and artefacts. We also present a theoretical model of how specific alignment practices affect different types of distances.ConclusionsThe results provide a basis for further research and can be used by software organisations to improve on software practice.     

Virtual organizational learning in open source software development projects

We studied virtual organizational learning in open source software (OSS) development projects. Specifically, our research focused on learning effects of OSS projects and the factors that affect the learning process. The number and percentage of resolved bugs and bug resolution time of 118 SourceForge.net OSS projects were used to measure the learning effects. Projects were characterized by project type, number and experience of developers, number of bugs, and bug resolution time. Our results provided evidence of virtual organizational learning in OSS development projects and support for several factors as determinants of performance. Team size was a significant predictor, with mid-sized project teams functioning best. Teams of three to seven developers exhibited the highest efficiency over time and teams of eight to 15 produced the lowest mean time for bug resolution. Increasing the percentage of bugs assigned to specific developers or boosting developer participation in other OSS projects also improved performance. Furthermore, project type introduced variability in project team performance.     

The impact of agile practices on communication in software development

Agile software development practices such as eXtreme Programming (XP) and SCRUM have increasingly been adopted to respond to the challenges of volatile business environments, where the markets and technologies evolve rapidly and present the unexpected. In spite of the encouraging results so far, little is known about how agile practices affect communication. This article presents the results from a study which examined the impact of XP and SCRUM practices on communication within software development teams and within the focal organization. The research was carried out as a case study in F-Secure where two agile software development projects were compared from the communication perspective. The goal of the study is to increase the understanding of communication in the context of agile software development: internally among the developers and project leaders and in the interface between the development team and stakeholders (i.e. customers, testers, other development teams). The study shows that agile practices improve both informal and formal communication. However, it further indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication. The study highlights the fact that hurdles and improvements in the communication process can both affect the feature requirements and task subtask dependencies as described in coordination theory. While the use of SCRUM and some XP practices facilitate team and organizational communication of the dependencies between product features and working tasks, the use of agile practices requires that the team and organization use also additional plan-driven practices to ensure the efficiency of external communication between all the actors of software development.

On the journey to continuous deployment: Technical and social challenges along the way

ContextContinuous Deployment (CD) is an emerging software development process with organisations such as Facebook, Microsoft, and IBM successfully implementing and using the process. The CD process aims to immediately deploy software to customers as soon as new code is developed, and can result in a number of benefits for organisations, such as: new business opportunities, reduced risk for each release, and prevent development of wasted software. There is little academic literature on the challenges organisations face when adopting the CD process, however there are many anecdotal challenges that organisations have voiced on their online blogs.ObjectiveThe aim of this research is to examine the challenges faced by organisations when adopting CD as well as the strategies to mitigate these challenges.MethodAn explorative case study technique that involves in-depth interviews with software practitioners in an organisation that has adopted CD was conducted to identify these challenges.ResultsThis study found a total of 20 technical and social adoption challenges that organisations may face when adopting the CD process. The results are discussed to gain a deeper understanding of the strategies employed by organisations to mitigate the impacts of these challenges.ConclusionWhile a number of individual technical and social adoption challenges were uncovered by the case study in this research, most challenges were not faced in isolation. The severity of these challenges were reduced by a number of mitigation strategies employed by the case study organisation. It is concluded that organisations need to be well prepared to handle technical and social adoption challenges with their existing expertise, processes and tools before adopting the CD process. For practitioners, knowing how to address the challenges an organisation may face when adopting the CD process provides a level of awareness that they previously may not have had.     

A conceptual framework to study the role of communication through social software for coordination in globally-distributed software teams

BackgroundIn Global Software Development (GSD) the lack of face-to-face communication is a major challenge and effective computer-mediated practices are necessary to mitigate the effect of physical distance. Communication through Social Software (SoSo) supports team coordination, helping to deal with geographical distance; however, in Software Engineering literature, there is a lack of suitable theoretical concepts to analyze and describe everyday practices of globally-distributed software development teams and to study the role of communication through SoSo.ObjectiveThe paper proposes a theoretical framework for analyzing how communicative and coordinative practices are constituted and maintained in globally-distributed teams.MethodThe framework is based on the concepts of communicative genres and coordination mechanisms; it is motivated and explicated through examples from two qualitative empirical cases.ResultsCoordination mechanisms and communicative genres mutually support each other. In particular, communication through SoSo supports team members in establishing, developing and maintaining social protocols within the distributed team. Software Engineering tools and methods provide templates for coordination mechanism that need to be adapted and adopted in order to support the project at hand. SoSo serves as a medium for the necessary metawork. The theoretical framework proposed is used to describe both the practices in an established industrial project and the establishing of practices in three student teams. The framework allows explaining the heterogeneity of practices observed.ConclusionsThis paper presents a conceptual framework to study the role of communication through SoSo for coordination in GSD. The usefulness of the framework is supported by empirical findings on the role of SoSo. The theoretical framework can be beneficial for future research that aims to analyze and describe not only the role of SoSo, but also how communicative and coordinative practices can be established and maintained in GSD teams.     

Interpretative case studies on agile team productivity and management

ContextThe management of software development productivity is a key issue in software organizations, where the major drivers are lower cost and shorter time-to-market. Agile methods, including Extreme Programming and Scrum, have evolved as “light” approaches that simplify the software development process, potentially leading to increased team productivity. However, little empirical research has examined which factors do have an impact on productivity and in what way, when using agile methods.ObjectiveOur objective is to provide a better understanding of the factors and mediators that impact agile team productivity.MethodWe have conducted a multiple-case study for 6 months in three large Brazilian companies that have been using agile methods for over 2 years. We have focused on the main productivity factors perceived by team members through interviews, documentation from retrospectives, and non-participant observation.ResultsWe developed a novel conceptual framework, using thematic analysis to understand the possible mechanisms behind such productivity factors. Agile team management was found to be the most influential factor in achieving agile team productivity. At the intra-team level, the main productivity factors were team design (structure and work allocation) and member turnover. At the inter-team level, the main productivity factors were how well teams could be effectively coordinated by proper interfaces and other dependencies and avoiding delays in providing promised software to dependent teams.ConclusionTeams should be aware of the influence and magnitude of turnover, which has been shown negative for agile team productivity. Team design choices remain an important factor impacting team productivity, even more pronounced on agile teams that rely on teamwork and people factors. The intra-team coordination processes must be adjusted to enable productive work by considering priorities and pace between teams. Finally, the revised conceptual framework for agile team productivity supports further tests through confirmatory studies.     

Acquiring and sharing tacit knowledge in software development teams: An empirical study

ContextSharing expert knowledge is a key process in developing software products. Since expert knowledge is mostly tacit, the acquisition and sharing of tacit knowledge along with the development of a transactive memory system (TMS) are significant factors in effective software teams.ObjectiveWe seek to enhance our understanding human factors in the software development process and provide support for the agile approach, particularly in its advocacy of social interaction, by answering two questions: How do software development teams acquire and share tacit knowledge? What roles do tacit knowledge and transactive memory play in successful team performance?MethodA theoretical model describing the process for acquiring and sharing tacit knowledge and development of a TMS through social interaction is presented and a second predictive model addresses the two research questions above. The elements of the predictive model and other demographic variables were incorporated into a larger online survey for software development teams, completed by 46 software SMEs, consisting of 181 individual team members.ResultsOur results show that team tacit knowledge is acquired and shared directly through good quality social interactions and through the development of a TMS with quality of social interaction playing a greater role than transactive memory. Both TMS and team tacit knowledge predict effectiveness but not efficiency in software teams.ConclusionIt is concluded that TMS and team tacit knowledge can differentiate between low- and high-performing teams in terms of effectiveness, where more effective teams have a competitive advantage in developing new products and bringing them to market. As face-to-face social interaction is key, collocated, functionally rich, domain expert teams are advocated rather than distributed teams, though arguably the team manager may be in a separate geographic location provided that there is frequent communication and effective use of issue tracking tools as in agile teams.     

Antecedents and consequences of team potency in software development projects

Developing new software quickly, successfully, and at low cost is critical in organizations. Ways of assessing the effectiveness of development teams has highlighted measures of factors, such as teamwork, group cohesiveness, and team integration, but the use of group potency theory (the collective belief of a group that it can be effective) is rare. In our study, we investigated antecedents of and consequences to group potency in software development project teams. By examining 53 software development project teams collected from small and medium-sized software firms in Turkey, we found, that team potency positively affected speed-to-market, development cost, and market success of the product. We also found that trust among project team members, past experiences of the members, and team empowerment had a positive impact on the team potency during the project. Managerial and theoretical implications are discussed.     

Performance on agile teams: Relating iteration objectives and critical decisions to project management success factors

ContextWhile project management success factors have long been established via the golden triangle, little is known about how project iteration objectives and critical decisions relate to these success factors. It seems logical that teams’ iteration objectives would reflect project management success factors, but this may not always be the case. If not, how are teams’ objectives for iterations differing from the golden triangle of project management success factors?ObjectiveThis study identifies iteration objectives and the critical decisions that relate to the golden triangle of project management success factors in agile software development teams working in two-week iterations.MethodThe author conducted semi-structured interviews with members across three different agile software development teams using a hybrid of XP and Scrum agile methodologies. Iteration Planning and Retrospective meetings were also observed. Interview data was transcribed, coded and reviewed by the researcher and two independently trained research assistants. Data analysis involved organizing the data to identify iteration objectives and critical decisions to identify whether they relate to project management success factors.ResultsAgile teams discussed four categories of iteration objectives: Functionality, Schedule, Quality and Team Satisfaction. Two of these objectives map directly to two aspects of the golden triangle: schedule and quality. The agile teams’ critical decisions were also examined to understand the types of decisions the teams would have made differently to ensure success, which resulted in four categories of such decisions: Quality, Dividing Work, Iteration Amendments and Team Satisfaction.ConclusionThis research has contributed to the software development and project management literature by examining iteration objectives on agile teams and how they relate to the golden triangle of project management success factors to see whether these teams incorporate the golden triangle factors in their objectives and whether they include additional objectives in their iterations. What’s more, this research identified four critical decisions related to the golden triangle. These findings provide important insight to the continuing effort to better assess project management success, particularly for agile teams.     

Motivation in software engineering industrial practice: A cross-case analysis of two software organisations

ContextThe research about motivation in software engineering has provided important insights into characterizing factors and outcomes related to motivation. However, the complex relationships among these factors, including the moderating and mediating effects of organisational and individual characteristics, still require deeper explanatory investigation.ObjectiveOur general goal is to build explanatory theories of motivation in different software organisations and to integrate these local theories towards a comprehensive understanding of the role of motivation in the effectiveness of the individuals and the teams in which they work. In this article, we describe the integrative synthesis of the results of two case studies performed with software organisations in different business contexts.MethodWe performed two case studies using a multiple-case, replication design, focusing on the software engineers as the unit of analysis. For 13 months, we conducted semi structured interviews, diary studies, and document analyses, and analysed the collected data using grounded theory procedures. The results of the two cases were synthesized using a meta-ethnography supported process.ResultsWe built translations of the concepts and propositions from the two studies into one another. We then used the translations to build a central story of motivation that synthesizes the individual stories. This synthesis is contextualized by the differences in organisational and individual characteristics.ConclusionThe differences in organisational contexts and in the characteristics of the software engineers in each study provided rich explanations for contrasts in perceptions and feelings about motivation in both organisations. The theory that emerged from the synthesis, supported by these explanations, provides a deeper understanding of the interplay between motivators and outcomes, and the needs and personal goals of the software engineers. This theory also characterises the role of team cohesion in motivation, advancing previous models about motivation in software engineering.     

Coproduction in successful software development projects

ContextCoproduction of new products has been deemed successful in organizational partnerships by adding to the quality and scope of the product. Techniques that involve users during the development of software tend to mimic this environment, but differ in the type of product and internal client roles. The question is thus, whether coproduction improves the outcomes of a software development project as it has in other disciplines.ObjectiveThis paper evaluates how the coproduction relationship between software developers and users improves the outcomes of a development project. Coproduction is believed to improve outcomes when available knowledge is accessible and applicable to the objective of the development project. Should the relationships hold, coproduction approaches to development can be approached with confidence and improvements made by attention to the development and deployment of expertise.MethodA quantitative questionnaire related to the coproduction environment was developed for four variables to include coproduction, applying expertise, locating expertise, and project success. 128 users from development teams responded to the survey and represent a variety of industries, individual characteristics, and project sizes.ResultsExpertise is crucial to the success of a software development project and coproduction improves the ability to access and apply the needed expertise. In addition, coproduction directly improves outcomes.ConclusionCoproduction can be an effective approach to the development of systems in terms of meeting project goals. Additionally, the assembly of expertise on the team is an important contributor to successful outcomes that may be enhanced through effective selection of team members. The ability to locate the available expertise is crucial, indicating the value of team building functions to promote awareness of expertise location.     

Are team personality and climate related to satisfaction and software quality? Aggregating results from a twice replicated experiment

ContextResearch into software engineering teams focuses on human and social team factors. Social psychology deals with the study of team formation and has found that personality factors and group processes such as team climate are related to team effectiveness. However, there are only a handful of empirical studies dealing with personality and team climate and their relationship to software development team effectiveness.ObjectiveWe present aggregate results of a twice replicated quasi-experiment that evaluates the relationships between personality, team climate, product quality and satisfaction in software development teams.MethodOur experimental study measures the personalities of team members based on the Big Five personality traits (openness, conscientiousness, extraversion, agreeableness, neuroticism) and team climate factors (participative safety, support for innovation, team vision and task orientation) preferences and perceptions. We aggregate the results of the three studies through a meta-analysis of correlations. The study was conducted with students.ResultsThe aggregation of results from the baseline experiment and two replications corroborates the following findings. There is a positive relationship between all four climate factors and satisfaction in software development teams. Teams whose members score highest for the agreeableness personality factor have the highest satisfaction levels. The results unveil a significant positive correlation between the extraversion personality factor and software product quality. High participative safety and task orientation climate perceptions are significantly related to quality.ConclusionsFirst, more efficient software development teams can be formed heeding personality factors like agreeableness and extraversion. Second, the team climate generated in software development teams should be monitored for team member satisfaction. Finally, aspects like people feeling safe giving their opinions or encouraging team members to work hard at their job can have an impact on software quality. Software project managers can take advantage of these factors to promote developer satisfaction and improve the resulting product.     

Sociomaterial bricolage: The creation of location-spanning work practices by global software developers

Context

Studies on global software development have documented severe coordination and communication problems among coworkers due to geographic dispersion and consequent dependency on technology. These problems are exacerbated by increase in the complexity of work undertaken by global teams. However, despite these problems, global software development is on the rise and firms are adopting global practices across the board, raising the question: What does successful global software development look like and what can we learn from its practitioners?

Objective

This study draws on practice-based studies of work to examine successful work practices of global software developers. The primary aim of this study was to understand how workers develop practices that allow them to function effectively across geographically dispersed locations.

Method

An ethnographically-informed field study was conducted with data collection at two international locations of a firm. Interview, observation and archival data were collected. A total of 42 interviews and 3 weeks of observations were conducted.

Results

Teams spread across different locations around the world developed work practices through sociomaterial bricolage. Two facets of technology use were necessary for the creation of these practices: multiplicity of media and relational personalization at dyadic and team levels. New practices were triggered by the need to achieve a work-life balance, which was disturbed by global development. Reflecting on my role as a researcher, I underscore the importance of understanding researchers’ own frames of reference and using research practices that mirror informants’ work practices.

Conclusion

Software developers on global teams face unique challenges which necessitate a shift in their work practices. Successful teams are able to create practices that span locations while still being tied to location based practices. Inventive use of material and social resources is central to the creation of these practices.