Cross-Disciplinary Virtual Design Teams

Software development teams that work together well, particularly those that can operate virtually, are an enormous competitive advantage for organizations (Cohen & Gibson, 2003). One challenge for software development or new product development teams in a global marketplace is managing and developing individuals from different disciplines who are remotely located. Such teams often encounter communication, environmental and philosophical barriers related to completing design tasks that threaten the success of projects (Warkenton, Sayeed & Hightower, 1997). For students at the university level, virtual cross-disciplinary learning experiences are key to their success in the competitive marketplace. The authors are currently in the second phase of an ongoing project designed to explore pedagogical, communications and logistical issues related to development of a sense of community between graduate students in the United Kingdom (UK) and United States (U.S.) (Schaffer et.al., 2005). One of the main goals of the current phase is to learn more about how virtual cross-disciplinary teams communicate and learn the concepts, models and discipline-specific language used by one another, as well as to identify key barriers and supports to such learning. Request access from your librarian to read this chapter's full text.

Investigating the effects of time pressure on new product development teams

Managers recognize that software development project teams need to be developed and guided.Although technical skills are necessary, non-technical (NT) skills are equally, if not more, necessary for project success.Currently, there are no proven tools to measure the NT skills of software developers or software development teams.Behavioral markers (observable behaviors that have positive or negative impacts on individual or team performance) are beginning to be successfully used by airline and medical industries to measure NT skill performance.The purpose of this research is to develop and validate the behavior marker system tool that can be used by different managers or coaches to measure the NT skills of software development individuals and teams.This paper presents an empirical study conducted at the Software Factory where users of the behavior marker tool rated video clips of software development teams.The initial results show that the behavior marker tool can be reliably used with minimal training.

Changes in Indian workforce and globalisation have resulted in an increase in heterogeneous information technology (IT) teams. Team heterogeneity has been shown to impact various team outcomes. This paper examines the impact of demographic, knowledge and underlying diversity in IT teams on various team outcomes. Data were collected from 62 software development (SD) teams and analysed using multiple regressions. The result suggests that more than other forms of heterogeneity, underlying heterogeneity in SD teams has been consistently a significant predictor of the various team outcomes and thus impacts the team effectiveness.

Context: It is known that men practitioners are predominant in software development teams over women. In recent years, researchers have investigated gender inequality from different perspectives, such as gender bias and suggestions to increase diversity in development teams. However, while most of the existing literature investigates the perception of women practitioners, the vast majority of the software development workforce – men – has received less attention. Goal: This work investigates men’s perceptions of gender inequality in software development teams and their experiences compared in software development to women. Method: Our study conducted a survey with 217 male practitioners, using a questionnaire consisting of 27 questions. The collected data was analyzed using a combination of quantitative and qualitative techniques, including graphical representations, percentages, and the grounded theory methodology. Results: Our findings reveal that most men do not perceive any sexist behavior among their team members and they are satisfied with the performance of their functions. In addition, their main suggestions to increase their participation in software development projects are offering training courses and improving the interaction among team members. Conclusions: The barriers and challenges that men practitioners face in software development teams are not the same as those faced by women. In addition, they consider that women do not work in software development due to a lack of affinity and knowledge about coding.

Developing a complex product in a concurrent engineering environment requires managing information flow among ten or even hundreds of people of different specialties organized in a large number of product development (PD) teams. Managing these teams effectively requires understanding the level of information dependencies among them which are often vague and cannot be precisely predicted. Taking into account the limitations of relevant previous studies, this article proposes a fuzzy-social network analysis approach for modeling and analyzing the information flow among PD teams. The approach involves four major steps: mapping of dependencies, measuring the level of information dependencies based on the fuzzy set theory, visualizing the network, and performing quantitative analysis using three measures (network density, in-degree centrality, and out-degree centrality). To validate its practicality, the approach is used to model and analyze the dependencies among 22 PD teams in a real project adapted from the literature and involved developing an automobile engine. An advantage of the approach is that in addition to providing a holistic view of the interactions among PD teams, it permits PD project managers to identity the most important PD teams with respect to information flow control using a proposed new classification system that classifies PD teams under four categories: autonomous, receivers, transmitters, and transceivers.

In this paper, we identify a set of factors that may be used to forecast software productivity and software development time. Software productivity was measured in function points per person hours, and software development time was measured in number of elapsed days. Using field data on over 130 field software projects from various industries, we empirically test the impact of team size, integrated computer aided software engineering (ICASE) tools, software development type, software development platform, and programming language type on the software development productivity and development time. Our results indicate that team size, software development type, software development platform, and programming language type significantly impact software development productivity. However, only team size significantly impacts software development time. Our results indicate that effective management of software development teams, and using different management strategies for different software development type environments may improve software development productivity.

Methods for Monitoring Productivity in Applicative Software Development

The NA-42 TI program initiated an effort in FY2010 to standardize its software development efforts with the long term goal of migrating toward a software management approach that will allow for the sharing and reuse of code developed within the TI program, improve integration, ensure a level of software documentation, and reduce development costs. The Pacific Northwest National Laboratory (PNNL) has been tasked with two activities that support this mission. PNNL has been tasked with the identification, selection, and implementation of a Shared Software Component Library. The intent of the library is to provide a common repository that is accessible by all authorized NA-42 software development teams. The repository facilitates software reuse through a searchable and easy to use web based interface. As software is submitted to the repository, the component registration process captures meta-data and provides version control for compiled libraries, documentation, and source code. This meta-data is then available for retrieval and review as part of library search results. In FY2010, PNNL and staff from the Remote Sensing Laboratory (RSL) teamed up to develop a software application with the goal of replacing the aging Aerial Measuring System (AMS). The application under development includes an Advanced Visualization and Integration of Data (AVID) framework and associated AMS modules. Throughout development, PNNL and RSL have utilized a common AMS code repository for collaborative code development. The AMS repository is hosted by PNNL, is restricted to the project development team, is accessed via two different geographic locations and continues to be used. The knowledge gained from the collaboration and hosting of this repository in conjunction with PNNL software development and systems engineering capabilities were used in the selection of a package to be used in the implementation of the software component library on behalf of NA-42 TI. The second task managed by PNNL is the development and continued maintenance of the NA-42 TI Software Development Questionnaire. This questionnaire is intended to help software development teams working under NA-42 TI in documenting their development activities. When sufficiently completed, the questionnaire illustrates that the software development activities recorded incorporate significant aspects of the software engineering lifecycle. The questionnaire template is updated as comments are received from NA-42 and/or its development teams and revised versions distributed to those using the questionnaire. PNNL also maintains a list of questionnaire recipients. The blank questionnaire template, the AVID and AMS software being developed, and the completed AVID AMS specific questionnaire are being used as the initial content to be established in the TI Component Library. This report summarizes the approach taken to identify requirements, search for and evaluate technologies, and the approach taken for installation of the software needed to host the component library. Additionally, it defines the process by which users request access for the contribution and retrieval of library content.

Background: Software organizations increasingly need developers with high skills for social interactions. Managers, leaders, and academics need to know the human factors influencing the individuals, the development team, and the software project activities. Despite the increasing number of secondary studies about human factors in Software Engineering (SE) and in Agile Software Development (ASD), there is no study synthesizing which human factors influence software development without a specific perspective from SE or human factor thematic. Objective: We aim to summarise human factors and their influence on SE development teams and ASD teams. Method: We executed a tertiary study. We used thematic analysis to examine the resulting data. Results: We found 29 systematic literature reviews and systematic mapping studies addressing the human perspective in SE teams. We identified 101 human factors and 79 influences grouped in 4 categories (Team member, Team, Project, and Organization). Also, we identified 71 human factors and 60 influences on ASD. The most investigated human factors are Communication, Collaboration, Knowledge, and Motivation. Conclusions: The identified human factors and their influences can be considered most significant by software organizations, researchers, and academics in SE practices. Based on our results, practitioners might propose activities that enhance human capital behaviors that influence individual motivation, agile mindset, team climate, software quality, or agile transition in traditional organizations.

Unlearning, which first appeared almost 30 years ago as a subprocess of the organizational learning process, has received only limited attention in the literature. Rather than building on empirical research, the existing scholarship is largely anecdotal, aimed at reviewing the literature and generating new insights. Further, unlearning studies tend to analyze the organizational level and neglect smaller units such as work groups and teams. To address this gap in the understanding of unlearning, this article empirically investigates unlearning in work groups in general and new product development (NPD) teams in particular. This study, based on the literature of organizational memory and change, operationalized team unlearning as changes in beliefs and routines during team‐based projects and then discussed the importance of unlearning behavior in NPD teams. Specifically it was argued that unlearning guards beliefs and routines against rigidity to cope with environmental turbulence. This is of particular note when rigid product development procedures and group beliefs inhibit the reception and evaluation of new market and technology information and reduce the value of perceived new information. To test the antecedents and consequences of the team unlearning model, 319 NPD teams were investigated. Using structural equation modeling, it was found that (1) team crisis and anxiety have a direct impact on team unlearning; (2) environmental turbulence also has a direct impact on both team crisis and anxiety and team unlearning; and (3) after team beliefs and project routines have changed, implementing new knowledge or information positively affects new product success. Specifically, the findings revealed that changes in team members' collective beliefs in accordance with environmental changes and the in‐process planning or adjustment of project work activities and procedures as the projects evolve enable teams to develop and launch new products successfully. Also, results indicated that team crisis and anxiety in NPD projects assist team members in revising their previous beliefs and routines when project teams are performing in turbulent environments. This article suggests that managers can enhance team unlearning by (1) creating a sense of urgency by introducing an artificial crisis; and (2) avoiding the groupthink phenomena by bringing in an outsider to challenge existing policies and procedures, and training the team on lateral thinking. In addition, managers can plan project activities in a flexible manner that allows changes as the project evolves to facilitate team unlearning. However, managers should also be cautious when promoting team unlearning. Without careful and considerable evaluation, change in beliefs and routines can cause information/knowledge loss.

In today's business environment, New Product Development (NPD) teams play a pivotal role in propelling innovation. Within NPD teams, both successful and failed projects contribute in enhancing learning processes, yet the epistemological pathways activated by successful projects differ distinctly from those stimulated by failed projects. In this study, we investigate the pathways towards team learning in the context of successful and failed NPD projects using fuzzy-set Qualitative Comparative Analysis (fsQCA). Drawing from the team learning literature, we examine which configurations of project characteristics (complexity and uncertainty), interpersonal team characteristics (innovation norms, cohesion, and decision-making autonomy), and environmental characteristics (technological and market turbulence) lead to NPD team learning. Our analysis identifies three configurations of factors tied to NPD team learning in successful projects and four configurations in failed projects. In successful projects, project and team characteristics are core in enhancing team learning. In failed projects, together with team characteristics, core conditions are represented by project complexity, uncertainty, while environmental characteristics play a dual role.

Technical debt are those convenience tasks that developers perform to obtain short-term benefits but that in the future can produce activities that are difficult to perform or more costly. The impact of technical debt is perceived in all project resources, becoming a present and future problem in software development, affecting the quality of the software. This study uses a qualitative analysis, through interviews with a software development team, explores the knowledge and perception of technical debt, the practices used to manage it, the factors that influence its appearance and accumulation, the impact that development suffers, as well as the team and the maintainability of the software, as a result, ideas and solutions are proposed to address it effectively. The study was carried out with a qualitative investigative approach, which was based on the study of a single case with which the experiences and practices in the perception and management of technical debt are investigated. The data obtained reveal that technical debt affects the normal development of the development team and that it is present in the activities carried out by the team. Although the development team has a perception of the debt, it does not address it directly, and it is necessary to implement good practices to identify it and integrate it into the software development process. Addressing technical debt with the implementation of a formal process to manage it will ensure that scheduled time is controlled and resources are optimized, which will result in a culture of good practices that will ensure product quality, improving team performance and guaranteeing software maintainability

Distributed software development is becoming a common practice among developers. Factors such as the development environments improvement, their extensibility, and the emergence of social networking software are leading factors. They lead the development process (both co-located and geographically distributed) to a practice that: 1) improves the team’s productivity, and 2) encourages and supports the social interaction among the teams’ members. The above factors along with the distributed development emergence, Integrated Development Environments (IDEs) evolution, and the social media advances got the attention of the software development teams, and made them consider how to better assist the social nature of software developers, and the social aspects of software development, including activity awareness of team members’ progress, their presence, collaboration, communication, and coordination around shared artifacts. IDEs are the most commonly used tools by developers and programmers. Integrating the most needed development tools inside the IDE, makes it a Collaborative Development Environment (CDE), and embedding a variety of social software features within a CDE helps support distributed development teams. It also creates a new genera of tools called Social Development Environments or “SDEs” as it is commonly called. This article discusses the origins and development of “SDEs”. It reflects and presents the research into development environments, explaining their role in supporting the communication and coordination needs of development teams. Also, it presents the effect of embedding social network features in such environments. It presents some emerging SDEs and future work. Finally, it concludes by introducing a new model named 5-star that classifies, and helps to evaluate and compare the collaborative tools. 5-star presents a new way to compare and evaluate the SDE systems based on their supported features. It bases the comparison on five major categories including: Communication, Coordination, Collaboration, Awareness & Presence, and Social networking (SN) tools.

The purpose of this mixed-methods study is to explore the effectiveness of Agile methods in addressing inefficiencies within software development projects, related issues, delays, excessive defects, and concerns with improved collaboration among the teams. This paper seeks to measure the value that Agile brings to organizations and recommend the implementation of these methods as a way of addressing the challenges that organizations experience when using conventional systems in software development. No changes to the basic Agile concept were made here and thus the research is based on methods that are already implemented such as Scrum and Kanban. Measures of productivity including project completion time, number of defects, and satisfaction level of the software development teams were obtained over six months from three companies. This research is innovative in the sense that it uses both the quantitative and qualitative methods in conducting the assessment to determine whether or not the Agile methodologies improve software development effectiveness and team performance in contrast to the Waterfall model. The results of this study indicate that Agile techniques enhanced productivity combined with the quality of team relations and can be used for further expansion in the sphere of software engineering. Therefore, it is recommended that Agile practices be implemented as a way of fixing problems that are standard in software development.