The effect of governance on global software development: An empirical research in transactive memory systems

ContextThe way global software development (GSD) activities are managed impacts knowledge transactions between team members. The first is captured in governance decisions, and the latter in a transactive memory system (TMS), a shared cognitive system for encoding, storing and retrieving knowledge between members of a group.ObjectiveWe seek to identify how different governance decisions (such as business strategy, team configuration, task allocation) affect the structure of transactive memory systems as well as the processes developed within those systems.MethodWe use both a quantitative and a qualitative approach. We collect quantitative data through an online survey to identify transactive memory systems. We analyze transactive memory structures using social network analysis techniques and we build a latent variable model to measure transactive memory processes. We further support and triangulate our results by means of interviews, which also help us examine the GSD governance modes of the participating projects. We analyze governance modes, as set of decisions based on three aspects; business strategy, team structure and composition, and task allocation.ResultsOur results suggest that different governance decisions have a different impact on transactive memory systems. Offshore insourcing as a business strategy, for instance, creates tightly-connected clusters, which in turn leads to better developed transactive memory processes. We also find that within the composition and structure of GSD teams, there are boundary spanners (formal or informal) who have a better overview of the network’s activities and become central members within their network. An interesting mapping between task allocation and the composition of the network core suggests that the way tasks are allocated among distributed teams is an indicator of where expertise resides.ConclusionWe present an analytical method to examine GSD governance decisions and their effect on transactive memory systems. Our method can be used from both practitioners and researchers as a “cause and effect” tool for improving collaboration of global software teams.     

Development of a team measure for tacit knowledge in software development teams

In this paper we operationally define and measure tacit knowledge at the team-level in the software development domain. Through a series of three empirical studies we developed and validated the team tacit knowledge measure (TTKM) for software developers. In the first study, initial scale items were developed using the repertory grid technique and content analysis. In Study 2, supplied repertory grids were administered to novices and experts to establish differential items, and Study 3 validated the TTKM on a sample of 48 industrial software development teams. In developing the TTKM we explored the relationships between tacit knowledge, explicit job knowledge and social interaction and their effect on team performance as measured by efficiency and effectiveness. In addition we assess the implications for managing software development teams and increasing team performance through social interaction.     

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.     

Communication and personality profiles of global software developers

ContextPrior research has established that a small proportion of individuals dominate team communication during global software development. It is not known, however, how these members’ contributions affect their teams’ knowledge diffusion process, or whether their personality profiles are responsible for their dominant presence.ObjectiveWe set out to address this gap through the study of repository artifacts.MethodArtifacts from ten teams were mined from the IBM Rational Jazz repository. We employed social network analysis (SNA) to group practitioners into two clusters, Top Members and Others, based on the numbers of messages they communicated and their engagement in task changes. SNA metrics (density, in-degree and closeness) were then used to study practitioners’ importance in knowledge diffusion. Thereafter, we performed psycholinguistic analysis on practitioners’ messages using linguistic dimensions that had been previously correlated with the Big Five personality profiles.ResultsFor our sample of 146 practitioners we found that Top Members occupied critical roles in knowledge diffusion, and demonstrated more openness to experience than the Others. Additionally, all personality profiles were represented during teamwork, although openness to experience, agreeableness and extroversion were particularly evident. However, no specific personality predicted members’ involvement in knowledge diffusion.ConclusionTask assignment that promotes highly connected team communication networks may mitigate tacit knowledge loss in global software teams. Additionally, while members expressing openness to experience are likely to be particularly driven to perform, this is not entirely responsible for a global team’s success.     

Enabling knowledge diversity to benefit cross-functional project teams: Joint roles of knowledge leadership and transactive memory system

Team members’ knowledge diversity has a “double-edged sword” nature within cross-functional project teams (CFPTs), showing an inconsistent relationship with team performance. For realizing this diversity’s potential benefits, leadership is usually an essential enabler. However, little is known about how knowledge leadership achieves this. This study proposed that knowledge leadership moderates the effect of knowledge diversity on team performance through a transactive memory system (TMS). By empirically testing survey data from 96 CFPTs, we found that knowledge leadership enables a positive linkage of knowledge diversity-CFPT performance by successively breaking down barriers to communication and cooperation in TMS development and functioning.     

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.     

Successful extreme programming: Fidelity to the methodology or good teamworking?

ContextDeveloping a theory of agile technology, in combination with empirical work, must include assessing its performance effects, and whether all or some of its key ingredients account for any performance advantage over traditional methods. Given the focus on teamwork, is the agile technology what really matters, or do general team factors, such as cohesion, primarily account for a team’s success? Perhaps the more specific software engineering team factors, for example the agile development method’s collective ownership and code management, are decisive.ObjectiveTo assess the contribution of agile methodology, agile-specific team methods, and general team factors in the performance of software teams.MethodWe studied 40 small-scale software development teams which used Extreme Programming (XP). We measured (1) the teams’ adherence to XP methods, (2) their use of XP-specific team practices, and (3) standard team attributes, as well as the quality of the project’s outcomes. We used Williams et al.’s (2004a) [33] Shodan measures of XP methods, and regression analysis.ResultsAll three types of variables are associated with the project’s performance. Teamworking is important but it is the XP-specific team factor (continuous integration, coding standards, and collective code ownership) that is significant. Only customer planning (release planning/planning game, customer access, short releases, and stand-up meeting) is positively related to performance. A negative relationship between foundations (automated unit tests, customer acceptance tests, test-first design, pair programming, and refactoring) is found and is moderated by craftsmanship (sustainable pace, simple design, and metaphor/system of names). Of the general team factors only cooperation is related to performance. Cooperation mediates the relationship between the XP-specific team factor and performance.ConclusionClient and team foci of the XP method are its critical active ingredients.     

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.     

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.     

Knowledge networks in new product development projects: A transactive memory perspective

Even though an individual's knowledge network is known to contribute to the effectiveness and efficiency of his or her work in groups, the way that network building occurs has not been carefully investigated. In our study, activities of new product development teams were analyzed to determine the antecedents and consequences on the transactive memory systems, the moderating affect of task complexity was also considered. We examined 69 new product development projects and found that team stability, team member familiarity, and interpersonal trust had a positive impact on the transactive memory system and also had a positive influence on team learning, speed-to-market, and new product success. Further, we found that the impact of the transactive memory system on team learning, speed-to-market, and new product success was higher when there was a higher task complexity. Theoretical and managerial implications of the study findings are discussed.     

Why does site visit matter in global software development: A knowledge-based perspective

ContextFace-to-Face (F2F) interaction is a strong means to foster social relationships and effective knowledge sharing within a team. However, communication in Global Software Development (GSD) teams is usually restricted to computer-mediated conversation that is perceived to be less effective and interpersonal. Temporary collocation of dispersed members of a software development team is a well-known practice in GSD. Despite broad realization of the benefits of visits, there is lack of empirical evidence that explores how temporary F2F interactions are organized in practice and how they can impact knowledge sharing between sites.ObjectiveThis study aimed at empirically investigating activities that take place during temporary collocation of dispersed members and analyzing the outcomes of the visit for supporting and improving knowledge sharing.MethodWe report a longitudinal case study of a GSD team distributed between Denmark and Pakistan. We have explored a particular visit organized for a group of offshore team members visiting onshore site for two weeks. Our findings are based on a systematic and rigorous analysis of the calendar entries of the visitors during the studied visit, several observations of a selected set of the team members’ activities during the visit and 13 semi-structured interviews.ResultsLooking through the lens of knowledge-based theory of the firm, we have found that social and professional activities organized during the visit, facilitated knowledge sharing between team members from both sites. The findings are expected to contribute to building a common knowledge and understanding about the role and usefulness of the site visits for supporting and improving knowledge sharing in GSD teams by establishing and sustaining social and professional ties.     

How do personality,team processes and task characteristics relate to job satisfaction and software quality?

This article analyses the relationships between personality, team processes, task characteristics, product quality and satisfaction in software development teams. The data analysed here were gathered from a sample of 35 teams of students (105 participants). These teams applied an adaptation of an agile methodology, eXtreme Programming (XP), to develop a software product. We found that the teams with the highest job satisfaction are precisely the ones whose members score highest for the personality factors agreeableness and conscientiousness. The satisfaction levels are also higher when the members can decide how to develop and organize their work. On the other hand, the level of satisfaction and cohesion drops the more conflict there is between the team members. Finally, the teams exhibit a significant positive correlation between the personality factor extraversion and software product quality.     

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.     

When agile meets the enterprise

ContextWhile renowned agile methods like XP and Scrum were initially intended for projects with small teams, traditional enterprise environments, i.e. environments where plan-driven development is prevalent, have also become attracted by the promises of a faster time to market through agility. Agile software development methods emphasize lightweight software development. Projects within enterprise environments, however, are typically confronted with a large and complex IT landscape, where mission-critical information is at play whose criticality requires prudence regarding design and development. In many an organization, both approaches are used simultaneously.ObjectiveFind out which challenges the co-existence of agile methods and plan-driven development brings, and how organizations deal with those challenges.MethodWe present a grounded theory of the challenges of using agile methods in traditional enterprise environments, based on a Grounded Theory research involving 21 agile practitioners from two large enterprise organizations in the Netherlands.ResultsWe organized the challenges under two factors: Increased landscape complexity and Lack of business involvement. For both factors, we identify successful mitigation strategies. These mitigation strategies concern the communication between the agile and traditional part of the organization, and the timing of that communication.ConclusionAgile practices can coexist with plan-driven development. One should, however, keep in mind the context and take actions to mitigate the challenges incurred.     

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.     

Understanding the role of behavioural integration in ISD teams: an extension of transactive memory systems concept

The transactive memory system (TMS) has been considered as one critical element for effective teamwork. However, viewing TMS as a second‐order construct that mixes cognitive (specialty and credibility) and behavioural (coordination) components leads to confusion and increases the difficulty in interpreting study results. This study follows the concept proposed by one recent study and attempts to distinguish between behavioural and cognitive components. Furthermore, drawing on the need for diverse members to be integrated behaviourally, we also attempt to extend the TMS research stream by proposing a more comprehensive behavioural component of TMS. We argue that to obtain better teamwork outcomes, information system development (ISD) team members need to integrate the expertise possessed by each individual, make decisions jointly and interlink all individual actions. In light of this, our study aims to replace coordination with team behavioural integration, a more comprehensive behavioural consequence of cognition and explore the critical role of behavioural integration in ISD teams by understanding its impact on ISD teamwork project team performance. The study result, based on data collected from 205 information system project managers, supports our hypotheses that expertise specialty, credibility and their interaction positively affect team behavioural integration. This, in turn, leads to enhanced project team performance.     

A model-driven approach to adopt good practices for agile process configuration and certification

ContextThe agile development paradigm has been extensively adopted in the industry. This adoption is highly dependent on the knowledge and good practices applied by most experienced practitioners in organizations. Hence, it would be valuable to count on appropriate support to preserve and systematically use this expert knowledge in configuring agile development processes aligned with organizational standards.ObjectiveThis paper presents a model-driven approach for representing and selecting good practices to configure agile practices in development processes aligned with organizational development practices and quality standards.MethodWe define a conceptual approach for configuring agile development processes that fulfills enterprise good practices and external quality standards. This approach was implemented in a tool suite and applied to an industrial development scenario related to ISO 9001 certification.ResultsThe approach was implemented in a model-driven tool that provides automatic support for identifying good practices when configuring agile development processes. The tool also verifies consistency with development methods and quality standards, such as ISO 9001.ConclusionsThe results obtained from the industrial application indicate that practitioners can reuse expert knowledge to configure agile development processes aligned with quality certifications. Moreover, the approach also facilitates the tailoring of agile practices into concrete development processes that take advantage of organizational good practices.     

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.     

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.     

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.