The IT industry has undergone a significant transformation over the past years, and many companies and software teams have been experimenting with different policies and work arrangements. In this multiple-case study, we explore the evolution of organizational policies and the work arrangements of 28 agile teams, and report on their effects, based on interviews with seven individuals in leadership and support roles, from six companies. Our findings reveal the emergence of a dynamic and evolving spectrum of work arrangements and organizational policies, reflecting an increased flexibility in accommodating diverse work schedules and locations. We identified complex and interrelated impacts at the organizational, leadership, and team levels. At the organizational level, underutilized office spaces pose new challenges for resource management and strategic planning. At the leadership level, managers and team leaders reported diminished visibility and awareness of team activities under certain arrangements. At the team level, policies reshaped the physical and virtual workspace, influencing creativity, communication patterns, and coordination demands, with some arrangements requiring enhanced mechanisms for coordination. Our findings further substantiate concerns raised by both scholars and managers about the impacts of evolving organizational policies and work arrangements.

When humans are exposed to environmental and physical stressors, cognitive performance is degraded. Even though several studies have examined the effect of various stressors individually, there are limited studies comparing the impact of different types. This study examined the effects of Heat, Noise, and Alcohol on cognitive performance during two programming tasks to quantify the impact of stressors on novice programmers. The experiment enrolled N=100 university student volunteers for a between-subjects experiment. Participants were randomly assigned to one of four conditions (M=25): a room with at 38 °C (100 °F), a room with conversational noise around 80 dBA, a blood alcohol content of 1.0‰, or a base condition. Two programming tasks were administered: one analysis task (reading programs) and one synthesis task (writing programs), taking about half an hour to complete in total. Short-term exposure to heat appears to not significantly affect neither reading nor writing programs; conversational noise significantly impacts analytical tasks but not synthesis tasks; while alcohol significantly worsens performance in both analytical and synthesis tasks. To provide a tangible summary for decision-makers able to influence conditions for novice programmers, an approximated comparison is provided, which “translates” negative cognitive effects of heat, noise, and alcohol to one another.

Abstract This paper presents the design of eight tools for working with psychological safety in agile software teams, which were designed in collaboration with industry practitioners using design science. The tools were adopted over a two-week period by four Danish industry software teams and evaluated through team interviews and surveys. Results show that the designed tools can be successfully adopted and integrated in the practices of a software team. Participating teams found the tool format valuable, as it allowed them (i) to engage in discussions they were not always capable of having, (ii) to find the right shared vocabulary to frame these discussions, and (iii) to provide them with needed prompts to let such discussion surface. Finally, teams unanimously reported interest in the continued use of the designed tools.

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Abstract Hardly any software development process is used as prescribed by authors or standards. Regardless of company size or industry sector, a majority of project teams and companies use hybrid development methods (short: hybrid methods) that combine different development methods and practices. Even though such hybrid methods are highly individualized, a common understanding of how to systematically construct synergetic practices is missing. In this article, we make a first step towards a statistical construction procedure for hybrid methods. Grounded in 1467 data points from a large‐scale practitioner survey, we study the question: What are hybrid methods made of and how can they be systematically constructed? Our findings show that only eight methods and few practices build the core of modern software development. Using an 85% agreement level in the participants' selections, we provide examples illustrating how hybrid methods can be characterized by the practices they are made of. Furthermore, using this characterization, we develop an initial construction procedure, which allows for defining a method frame and enriching it incrementally to devise a hybrid method using ranked sets of practice.

Selecting a suitable development method for a specific project context is one of the most challenging activities in process design. Every project is unique and, thus, many context factors have to be considered. Recent research took some initial steps towards statistically constructing hybrid development methods, yet, paid little attention to the peculiarities of context factors influencing method and practice selection. In this paper, we utilize exploratory factor analysis and logistic regression analysis to learn such context factors and to identify methods that are correlated with these factors. Our analysis is based on 829 data points from the HELENA dataset. We provide five base clusters of methods consisting of up to 10 methods that lay the foundation for devising hybrid development methods. The analysis of the five clusters using trained models reveals only a few context factors, e.g., project/product size and target application domain, that seem to significantly influence the selection of methods. An extended descriptive analysis of these practices in the context of the identified method clusters also suggests a consolidation of the relevant practice sets used in specific project contexts.

When software products and services are developed and maintained over longer time, software engineering practices tend to drift away from both structured and agile methods. Nonetheless, in many cases the evolving practices are far from ad hoc or chaotic. How are the teams involved able to coordinate their joint development?This article reports on an ethnographic study of a small team at a successful provider of software as a service. What struck us was the very explicit way in which the team adopted and adapted their practices to fit the needs of the evolving development. The discussion relates the findings to the concepts of social practices and methods in software engineering, and explores the differences between degraded behavior and the coordinated evolution of development practices. The analysis helps to better understand how software engineering practices evolve, and thus provides a starting point for rethinking software engineering methods and their relation to software engineering practice.

Among the multitude of software development processes available, hardly any is used by the book. Regardless of company size or industry sector, a majority of project teams and companies use customized processes that combine different development methods--so-called hybrid development methods. Even though such hybrid development methods are highly individualized, a common understanding of how to systematically construct synergetic practices is missing. In this paper, we make a first step towards devising such guidelines. Grounded in 1,467 data points from a large-scale online survey among practitioners, we study the current state of practice in process use to answer the question: What are hybrid development methods made of? Our findings reveal that only eight methods and few practices build the core of modern software development. This small set allows for statistically constructing hybrid development methods. Using an 85% agreement level in the participants' selections, we provide two examples illustrating how hybrid development methods are characterized by the practices they are made of. Our evidence-based analysis approach lays the foundation for devising hybrid development methods.

Even though agile methods have been flourishing in the last decades, their implementation in (globally) distributed arrangements still present hard challenges. Due to this tension, practices are either modified or added to compensate with the additional control required by the setup. In this paper, we present a case study about a company that managed to incrementally design a process that does not compromise the foundations of the agile philosophy by embracing the characteristics of distributed development. We show how a virtual work environment has been crafted by continuously improving practices and carefully selecting technologies to allow each team member to fully participate regardless of the actual physical location. Aware of the single nature limitation of the reported case, we present extensive information to frame the context allowing meaningful comparisons by researchers and providing concrete examples for practitioners.

Background: Agile and distributed software development are two trends that continue to increase rapidly in today's software industry. Even though the benefits achievable by combining them are potentially many, the intrinsic challenges of such marriage often lead to severe complications that can jeopardize the successful completion of software projects. Method: To investigate empirically how these two trends can coexist without compromising on the agile core values and principles, we conducted an exploratory holistic case study. Focusing on the development team of a Danish SME having both distributed offices as well as teleworking arrangements, we showcase (the evolution of) their practices. Results: The case is an example of the effective application of the agile reflective culture that allowed the company to evolve to a level in which the collocation restrictions of agile software development are overcome by a continuously evolving software process geared towards reducing waste to achieve speed and simplicity. Conclusions: Even though results need to be considered carefully due to the single nature of the reported case, we highlight five elements that have been fundamental in such journey: agile servant-leader, agile team, trust, virtual work environment, inspect & adapt, and reduce waste. Extensive information is provided to frame the context and to allow meaningful future comparisons.

Distributed software engineering and agility are strongly pushing on today's software industry. Due to inherent incompatibilities, for years, studying Scrum and its application in distributed setups has been subject to theoretical and applied research, and an increasing body of knowledge reports insights into this combination. Through a systematic literature review, this paper contributes a collection of experiences on the application of Scrum to global software engineering (GSE). In total, we identified 40 challenges in 19 categories practitioners face when using Scrum in GSE. Among the challenges, scaling Scrum to GSE and adopting practices accordingly are the most frequently named. Our findings also show that most solution proposals aim at modifying elements of the Scrum core processes. We thus conclude that, even though Scrum allows for extensive modification, Scrum itself represents a barrier for global software engineering, and development teams have to customize Scrum properly to benefit from agile software development in GSE.

Software and system development faces numerous challenges of rapidly changing markets. To address such challenges, companies and projects design and adopt specific development approaches by combining well-structured comprehensive methods and flexible agile practices. Yet, the number of methods and practices is large, and available studies argue that the actual process composition is carried out in a fairly ad-hoc manner. The present paper reports on a survey on hybrid software development approaches. We study which approaches are used in practice, how different approaches are combined, and what contextual factors influence the use and combination of hybrid software development approaches. Our results from 69 study participants show a variety of development approaches used and combined in practice. We show that most combinations follow a pattern in which a traditional process model serves as framework in which several fine-grained (agile) practices are plugged in. We further show that hybrid software development approaches are independent from the company size and external triggers. We conclude that such approaches are the results of a natural process evolution, which is mainly driven by experience, learning, and pragmatism.

Background: Even though a number of tools are reported to be used by researchers undertaking systematic reviews, important shortages are still reported revealing how such solutions are unable to satisfy current needs. Method: Two research groups independently provided a design for a tool supporting systematic reviews. The resulting tools were assessed against the feature lists provided by prior research. Results: After presenting an overview of the tools and the core design decisions taken, we provide a feature analysis and a discussion regarding selected challenges deemed crucial to provide a proper tool support. Conclusions: Although the designed solutions do not yet support the entire systematic review process, their architecture has been designed to be flexible and extendable. After highlighting the difficulties of developing appropriate tools, we call for action: developing tools to support systematic reviews is a community project.

For decades, Software Process Improvement (SPI) programs have been implemented, inter alia, to improve quality and speed of software development. To set up, guide, and carry out SPI projects, and to measure SPI state, impact, and success, a multitude of different SPI approaches and considerable experience are available. SPI addresses many aspects ranging from individual developer skills to entire organizations. It comprises for instance the optimization of specific activities in the software lifecycle as well as the creation of organization awareness and project culture. In the course of conducting a systematic mapping study on the state-of-the-art in SPI from a general perspective, we observed Global Software Engineering (GSE) becoming a topic of interest in recent years. Therefore, in this paper, we provide a detailed investigation of those papers from the overall systematic mapping study that were classified as addressing SPI in the context of GSE. From the main study's result set, a set of 30 papers dealing with GSE was selected for an in-depth analysis using the systematic review instrument to study the contributions and to develop an initial picture of how GSE is considered from the perspective of SPI. Our findings show the analyzed papers delivering a substantial discussion of cultural models and how such models can be used to better address and align SPI programs with multi-national environments. Furthermore, experience is shared discussing how agile approaches can be implemented in companies working at the global scale. Finally, success factors and barriers are studied to help companies implementing SPI in a GSE context.

Software engineering (SE) is predominantly a team effort that needs close cooperation among several people who may be geographically distributed. It has been recognized that appropriate tool support is a prerequisite to improve cooperation within SE teams. In an effort to contribute to this line of research, we have designed and developed an infrastructure, called ABC4GSD, based on the models of activity theory (AT) and the principles of the activity-based computing (ABC) paradigm. In this paper, we present a study that empirically evaluates the ability of ABC4GSD in supporting teams cooperation. We designed and executed a study based on a scenario that simulated the follow-the-Sun (FTS) strategy of global SE (GSE). Our research design allowed us to ensure cooperation to be both computer-mediated as well as contained within observable short time-windows - the hand-off activities of the FTS strategy. [Results] Overall, the results show that the cooperation support provided by the ABC4GSD system has been positively perceived by the participants. Nonetheless, open issues stimulating further investigations have been raised especially due to a few mixed results. Aware of the limitations of the simulated scenario, we conclude that the approach followed by the ABC4GSD system based on activities is desirable to improve the cooperation support in SE. Finally, our research approach based on simulating a scenario with geographical and temporal distribution can provide useful ideas for assessing collaborative technologies in SE.

Assessing the presence and availability of a remote colleague is key in coordination in global software development but is not easily done using existing computer-mediated channels. Previous research has shown that automated estimation of interruptibility is feasible and can achieve a precision closer to, or even better than, human judgment. However, existing approaches to assess interruptibility have been designed to rely on external sensors. In this paper, we present Approximator, a system that estimates the interruptibility of a user based exclusively on the sensing ability of commodity laptops. Experimental results show that the information aggregated from several activity monitors (i.e., Key-logger, mouse-logger, and face-detection) provide useful data, which, once combined with machine learning techniques, can automatically estimate the interruptibility of users with a 78% accuracy. These early but promising results represent a starting point for designing tools with support for interruptibility capable of improving distributed awareness and cooperation to be used in global software development.

Companies are increasingly organizing work in globally distributed teams. A core challenge to these distributed teams is, however, to maintain social relationships due to limited opportunities and tools for social engagement. In this paper we present SideBar: a videoconferencing system that enhance

Global Software Engineering (GSE) teams face challenges due to the need to replace traditional physical presence interactions and co-ordination with computer-mediated means. A vast majority of the available tool support for distributed collaboration is deep-seated in a desktop metaphor introduced in the `70s, and huge efforts are being devoted to overcome its known limitations. Over the last few years we have looked into the feasibility of providing an approach based on Activity-Based Computing (ABC) to address these issues in a novel way. We have developed a middleware and support tool, ABC4GSD, to enable collaborative distributed features in an application, while maintaining common interactions with the workstation that users are accustomed to. In this paper we present the results of a user evaluation we conducted on ABC4GSD using exemplar GSE scenarios. Participants' responses show positive and encouraging reception of the activity-based approach to supporting GSE.

Although a plethora of tools are available for Global Software Engineering (GSE) teams, it is being realized increasingly that the most prevalent desktop metaphor underpinning the majority of tools have several inherent limitations. We have proposed that Activity-Based Computing (ABC) can be a promising alternative to build tools for GSE. However, significant effort is required to introduce a new paradigm; there is a need of sound theoretical foundation based on activity theory to address challenges faced by tools in GSE. This paper reports our effort aimed at building theoretical foundations for applying activity theory to GSE. We analyze and explain the fundamental concepts of activity theory, and how they can be applied by using examples of software architecture design and evaluation processes. We describe the kind of data model and architectural support required for applying activity theory in building supporting infrastructure for GSE, and describe a proof of concept prototype.

Global software development (GSD) teams have to use multiple tools to perform both complex and even simple tasks involving many context switches that can be frustrating. To lessen these issues, researchers are looking at providing new plug-ins whereas commercial vendors are flooding the market with comprehensive solutions often in the form of platforms. The current file- and application- oriented desktop metaphor can hardly support the collaborative and distributed nature of GSD teams. We assert that the Activity-Based Computing (ABC) paradigm has the potential for addressing the tool support related challenges of GSD. We have been incrementally designing and developing a flexible middleware (ABC4GSD) for supporting ABC in GSD. In this paper we present the theoretical foundations underpinning our approach and the architectural overview of a middleware for supporting ABC in GSD. Moreover, we briefly present a prototype leveraging the features provided by the middleware as a proof of concept.