Technical Debt (TD) is a metaphor used to explain the negative impacts that sub-optimal design decisions have in the long-term perspective of a software project. Although TD is acknowledged by both researchers and practitioners to have strong negative impact on Software development, its study on Testware has so far been very limited. A gap in knowledge that is important to address due to the growing popularity of Testware (scripted automated testing) in software development practice.In this paper we present a mapping analysis that connects 21 well-known, Software, object-oriented TD items to Testware, establishing them as Testware Technical Debt (TTD) items. The analysis indicates that most Software TD items are applicable or observable as TTD items, often in similar form and with roughly the same impact as for Software artifacts (e.g. reducing quality of the produced artifacts, lowering the effectiveness and efficiency of the development process whilst increasing costs). In the analysis, we also identify three types of connections between software TD and TTD items with varying levels of impact and criticality. Additionally, the study finds support for previous research results in which specific TTD items unique to Testware were identified. Finally, the paper outlines several areas of future research into TTD. © 2017 IEEE.

Business process integration (BPI) is a crucial technique for supporting inter-organizational business interoperability. BPI allows automation of business processes and the integration of systems across numerous organizations. The integration of organizations' process models is one of the most addressed and used approach to achieve BPI. However, this model integration is complex and requires that designers have extensive experience in particular when organizations' business processes are incompatible. This paper considers the issue of modeling cross-organization processes out of a collection of organizations' private process models. To this end, we propose six adaptation patterns to resolve incompatibilities when combining organizations' processes. Each pattern is formalized with workflow net. © 2017 IEEE.

Today’s business processes become increasingly complex and often cross the boundaries of the organizations. On the one hand, to support their business processes, modern organizations use enterprise information systems that need to be aware of the organizations’ processes and contexts. Such systems are called Process-Aware Information System (PAIS). On the other hand, the service-oriented architecture (SOA) is a fast emerging architectural style that has been widely adopted by modern organizations to design and implement PAIS that support their business processes. This paper aims to bridge the gap between inter-organizational business processes and SOA-based PAISs that support them. It proposes a novel model-driven design method that generates SOA models expressed in SoaML taking the specification of collaborative business processes expressed in BPMN as input. We present the principles underlying the approach, the state of an ongoing implementation, and the results of two studies conducted to empirically validate the method in the context of ERP key processes. © 2018, Springer-Verlag London Ltd., part of Springer Nature.

Simulation is a powerful instrument in the education process that can help students experience a reality context and understand complex concepts required to accomplish practitioners' tasks. The present study aims to investigate the software engineering students' perception about the usefulness of the Planning Poker technique in relation to their understanding of the relative estimation concept. We conducted a simulation exercise where students first estimated tasks applying the concepts of relative estimation based on the concepts explained in the lecture, and then to estimate tasks applying the Agile Planning Poker technique. To investigate the students' perception, we used a survey at the end of each exercise. The preliminary results did not show statistical significance on the students' confidence to estimate relatively the user stories. However, from the students' comments and feedback, there are indications that students are more confident in using Agile Planning Poker when they are asked to estimate user stories. The study will be replicated in the near future to a different group of students with a different background, to have a better understanding and also identify possible flaws of the exercise. © 2018 Association for Computing Machinery.

Traditional business process modeling languages use an imperative style to specify all possible execution flows, leaving little flexibility to process operators. Such languages are appropriate for low-complexity, high-volume, mostly automated processes. However, they are inadequate for case management, which involves low-volume, high-complexity, knowledge-intensive work processes of today's knowledge workers. OMG's Case Management Model and Notation (CMMN), which uses a declarative style to specify constraints placed at a process execution, aims at addressing this need. To the extent that typical case management situations do include at least some measure of imperative control, it is legitimate to ask whether an analyst working exclusively in CMMN can comfortably model the range of behaviors s/he is likely to encounter. This paper aims at answering this question by trying to express the extensive collection of Workflow Patterns in CMMN. Unsurprisingly, our study shows that the workflow patterns fall into three categories: 1) the ones that are handled by CMMN basic constructs, 2) those that rely on CMMN's engine capabilities and 3) the ones that cannot be handled by current CMMN specification. A CMMN tool builder can propose patterns of the second category as companion modeling idioms, which can be translated behind the scenes into standard CMMN. The third category is problematic, however, since its support in CMMN tools will break model interoperability.

Context

Advances in technical debt research demonstrate the benefits of applying the financial debt metaphor to support decision-making in software development activities. Although decision-making during requirements engineering has significant consequences, the debt metaphor in requirements engineering is inadequately explored.

Objective

We aim to conceptualize how the debt metaphor applies to requirements engineering by organizing concepts related to practitioners’ understanding and managing of requirements engineering debt (RED).

Method

We conducted two in-depth expert interviews to identify key requirements engineering debt concepts and construct a survey instrument. We surveyed 69 practitioners worldwide regarding their perception of the concepts and developed an initial analytical theory.

Results

We propose a RED theory that aligns key concepts from technical debt research but emphasizes the specific nature of requirements engineering. In particular, the theory consists of 23 falsifiable propositions derived from the literature, the interviews, and survey results.

Conclusions

The concepts of requirements engineering debt are perceived to be similar to their technical debt counterpart. Nevertheless, measuring and tracking requirements engineering debt are immature in practice. Our proposed theory serves as the first guide toward further research in this area.

Business Process Model and Notation (BPMN) is becoming a de-facto standard for the specification of organizational business processes. In most cases, business processes are modeled in order to build software that may support or automate specific parts of those processes. In this work, we aim at refining BPMN models in order to automatically derive software analysis and design artifacts (e.g., UML Class Diagrams or Use Cases) from a given BPMN. These artifacts will be later on used to develop the software components (not necessarily services) automating or supporting business process activities. Our envisioned approach is based on a three-steps model transformation chain: (1) we refine the BPMN as-is model; (2) we apply process re-engineering and automation patterns to generate the BPMN to-be model; and (3) we use the resulting to-be BPMN model to derive analysis and design software artifacts. In this paper, we focus on the first two steps of the approach.

Practitioners on the area of mobile application development usually rely on set of app-related success factors, the majority of which are directly related to their economical/business profit (e.g., number of downloads, or the in-app purchases revenue). However, gathering also the user-related success factors, that explain the reasons why users choose, download, and install apps as well as the user-related failure factors that explain the reasons why users delete apps, might help practitioners understand how to improve the market impact of their apps. The objectives were to: identify (i) the reasons why users choose and installing mobile apps from app stores; (ii) the reasons why users uninstall the apps. A questionnaire-based survey involving 121 users from 26 different countries was conducted. © Springer International Publishing AG 2017.

Organizations build information systems to support their business processes. Precise modeling of an organization's processes is a prerequisite for building information systems that support those processes. Our goal is to help business analysts produce detailed models of the business processes that best reflect the needs of their organizations. To this end, we propose to a) leverage the best practices in terms of a kernel of generic business processes, and b) provide analysts with tools to customize those processes by generating new process variants. We use business patterns from the Resource Event Agent ontology to identify variation points, and to codify the transformations inherent in the generation of the process variants. We developed a prototype process specialization tool using the Eclipse modeling ecosystem. We tested our approach on a set of processes from the Enterprise Resource Planning literature, and a set of variation points to assess the extent to which: 1) the identified variation points made sense, and 2) whether the generated variants made sense, from a business point of view. The results showed that 94.12% of the variation points made sense, and that 80.6% of the generated process variants corresponded to what the business process management specialists expected.

Requirements are key artefacts to describe the intended purpose of a software system. The quality of requirements is crucial for deciding what to do next, impacting the development process’ effectiveness and efficiency. However, we know very little about the connection between practitioners’ perceptions regarding requirements quality and its impact on the process or the feelings of the professionals involved in the development process. Objectives: This study investigates: i) How software development practitioners define requirements quality, ii) how the perceived quality of requirements impact process and stakeholders’ well-being, and iii) what are the causes and potential solutions for poor-quality requirements. Method: This study was performed as a descriptive interview study at a sub-organization of a Nordic bank that develops its own web and mobile apps. The data collection comprises interviews with 20 practitioners, including requirements engineers, developers, testers, and newly employed developers, with five interviewees from each group. Results: The results show that different roles have different views on what makes a requirement good quality. Participants highlighted that, in general, they experience negative emotions, more work, and overhead communication when they work with requirements they perceive to be of poor quality. The practitioners also describe positive effects on their performance and positive feelings when they work with requirements that they perceive to be good. © 2023, The Author(s), under exclusive license to Springer Nature Switzerland AG.

Context: Writing code that is understandable by other collaborators has become crucial to enhancing collaboration and productivity. Clean Code has become one of the most relevant software craftsmanship practices and has been widely embraced as a synonym for code quality by software developers and software development organizations all over the world. However, very little is known regarding whether developers agree with Clean Code principles and how they apply them in practice.

Objectives: In this work, we investigated how developers perceive Clean Code principles, whether they believe that helps reading, understanding, reusing, and modifying Clean Code, and how they keep their code clean.

Methods: We conducted a Systematic Literature Review in which we screened 771 research papers to collect Clean Code principles and a survey among 39 practitioners, some of them with more than 20 years of development experience.

Results: So far, the results show a shared agreement with Clean Code principles and their potential benefits. They also show that developers tend to write “messy” code to be refactored later. © 2022, The Author(s), under exclusive license to Springer Nature Switzerland AG.

Background: Software project management courses are becoming popular for teaching software engineering process models and methods. However, in order to be effective, this approach should be properly aligned to the learning outcomes. Common misalignments are caused by using a correct degree of realism or an appropriate instruction level. Objective: To foster students to acquire knowledge (theoretical and practical) that enables them solving similar challenges to the ones they will face in real-world software projects. Methods: We prototype and validate a legacy game that simulates the software development process. Students are required to plan and manage a software project according to its specification provided by the teachers. Teachers act as both customers and moderators, presenting the challenges and guiding the students' teamwork. Results: Both students' and teachers' perception suggest that the proposed game has potential to motivate the knowledge acquisition through problem-solving. The feedback also suggests that some measures must be taken to ensure the pedagogical alignment and a fair game. Conclusion: The lessons learned provide suggestions for adopting this or similar games in the context of project courses. As further work, we plan to describe and extend the game rules based on the results of this application. © 2018 Association for Computing Machinery.

Internet of Things (IoT) is a growing technology that relies on connected ‘things’ that gather data from peer devices and send data to servers via APIs (Application Programming Interfaces). The design quality of those APIs has a direct impact on their understandability and reusability. This study focuses on the linguistic design quality of REST APIs for IoT applications and assesses their linguistic quality by performing the detection of linguistic patterns and antipatterns in REST APIs for IoT applications. Linguistic antipatterns are considered poor practices in the naming, documentation, and choice of identifiers. In contrast, linguistic patterns represent best practices to APIs design. The linguistic patterns and their corresponding antipatterns are hence contrasting pairs. We propose the SARAv2 (Semantic Analysis of REST APIs version two) approach to perform syntactic and semantic analyses of REST APIs for IoT applications. Based on the SARAv2 approach, we develop the REST-Ling tool and empirically validate the detection results of nine linguistic antipatterns. We analyse 19 REST APIs for IoT applications. Our detection results show that the linguistic antipatterns are prevalent and the REST-Ling tool can detect linguistic patterns and antipatterns in REST APIs for IoT applications with an average accuracy of over 80%. Moreover, the tool performs the detection of linguistic antipatterns on average in the order of seconds, i.e., 8.396 s. We found that APIs generally follow good linguistic practices, although the prevalence of poor practices exists.

In this paper, we present experiences from eight years of developing a financial transaction engine, using what can be described as an integration-test-centric software development process.We discuss the product and the relation between three different categories of its software and how the relative weight of these artifacts has varied over the years.In addition to the presentation, some challenges and future research directions are discussed.

Context The micro-services architectural pattern advocates for the partitioning of functionality into loosely coupled services, which should be backward compatible, to enable independent upgrades. Deprecation is commonly used as a tool to manage multiple versions of methods or services. However, deprecation carries a cost in that tests might be duplicated and might rely on services that have become deprecated over time. Objective Using the terms of the Technical Debt metaphor, we explore the consequences of deprecation, and how it has affected the test base during seven years. Method We take an exploratory approach, reporting on experiences found before and after servicing parts of the incurred Technical Debt. We mine code repositories and validate our findings with experienced developers. Results We found that the growth of deprecation debt varied a lot. Some services experienced substantial growth, but most did not. Unit tests, where deprecation is visible in the developers' tools, were much less affected than integration tests, which lack such visualization mechanisms. While servicing debt of 121 out of 285 deprecated services, we discovered that up to 29% of the spent effort could be attributed to accrued interest. However, this is an upper bound; there could be less impact, depending on whether scripting could be used to service the debt or not. Conclusion This paper illustrates that integration tests can be viewed as a debt from the perspective of deprecated services. While the pattern was that deprecated services (debt principal) experienced no or little accrued interest, some, highly used, services experienced a lot, particularly during stressful times. Java-based tests, where deprecation is visible in the IDE, did not experience a similar pattern of increasing debt. We postulate that deprecation debt should be kept visible, either using developer tools or statistical reports. © 2020 ACM.

Since its inception, software development has been recognized as a highly technical activity, where, at times, highly skilled professionals have been tempted to face technical problems on their own. In the past, software developers, may have been inclined to create solutions as if they were the only ones who needed to understand the solutions.

However, nowadays, the disciplines of software development and systems development have undergone significant change. Current software development requires more crafting skills, in addition to engineering skills. The lone-cowboy programmer will soon have no place in properly organised software development projects. Current practices demand that a productive programmer be tasked to develop both working software (as claimed in the Agile Manifesto) and well crafted software. Accountability, pride in one's work, continuous learning and mentorship are characteristics of the profession that we should promote if we want to enable an attitude of craftsmanship within software development.

This paper provides experiences of craftsmanship, and argues why software craftsmanship is good for the practitioner and software development organizations. To support this claim, we have analysed the development of a product that was developed by following several craftsmanship principles. We observed the product's development for seven years, and interviewed several professionals who were involved in its development.

Context:   The concept of software craftsmanship has early roots in computing, and in 2009, the Manifesto for Software Craftsmanship was formulated as a reaction to how the Agile methods were practiced and taught. But software craftsmanship has seldom been studied from a software engineering perspective.  

Objective:  The objective of this article is to systematize an anatomy of software craftsmanship through literature studies and a longitudinal case study.     

Method:  We performed a snowballing literature review based on an initial set of nine papers, resulting in~18 papers and 11 books.  We also performed a case study following seven years of software development of a product for the financial market, eliciting qualitative and quantitative results.  We used thematic coding to synthesize the results into categories.

Results:  The resulting anatomy is centered around four themes, containing 17 principles and 47 hierarchical practices connected to the principles.  We present the identified practices based on the experiences gathered from the case study, triangulating with the literature results.

Conclusion: We provide our systematically derived anatomy of software craftsmanship with the goal of inspiring more research into the principles and practices of software craftsmanship and how these relate to other principles within software engineering in general.

Seeking the advantages delivered by agile methods in small-scale software development, large organisations are also adopting agile methods. However, scaling results in a huge growth of socio-technical dependencies that can lead to waiting time, delays, and defects and hinder the teams' ability to recognize their own responsibilities. This research proposes an approach to enable teams' autonomy and clarifies teams' responsibility assignments by aligning socio-technical dependencies. By utilising compile-time, run-time, and task dependencies, our approach identifies the wasteful dependencies between the social structures (teams) and the corresponding technical structures (architecture) and also suggests improvements. The initial results suggest that the approach correctly identifies the wasteful dependencies that are hindering teams' responsibility assignments. The suggested solution proposals are also considered useful. Awareness of such wasteful dependencies is the first step toward being able to handle them successfully. © 2023 IEEE.

Context: Technical Debt (TD) discusses the negative impact of sub-optimal decisions to cope with the need-for-speed in software development. Code Technical Debt Items (TDI) are atomic elements of TD that can be observed in code artifacts. Empirical results on open-source systems demonstrated how code-smells, which are just one type of TDIs, are introduced and "survive" during release cycles. However, little is known about whether the results on the survivability of code-smells hold for other types of code TDIs (i.e., bugs and vulnerabilities) and in industrial settings.Goal: Understanding the survivability of code TDIs by conducting an empirical study analyzing two industrial cases and 31 open-source systems from Apache Foundation. Method: We analyzed 144,476 code TDIs (35,372 from the industrial systems) detected by Sonarqube (in 193,196 commits) to assess their survivability using survivability models.Results: In general, code TDIs tend to remain and linger for long periods in open-source systems, whereas they are removed faster in industrial systems. Code TDIs that survive over a certain threshold tend to remain much longer, which confirms previous results. Our results also suggest that bugs tend to be removed faster, while code smells and vulnerabilities tend to survive longer.

When developing and maintaining software-intensive products or services, we often depend on various "assets", denoting the inherent value to selected artefacts when carrying out development and maintenance activities. When exploring various areas in Software Engineering, such as Technical Debt and our work with industry partners, we soon realised that many terms and concepts are frequently intermixed and used inconsistently. Despite the central role of assets to software engineering, management, and evolution, little thoughts are yet invested into what assets eventually are. A clear terminology of "assets" and related concepts, such as "value" or "value degradation", just to name two, are crucial for setting up effective software engineering practices.

As a starting point for our own work, we had to define the terminology and concepts, and extend the reasoning around the concepts. In this position paper, we critically reflect upon the resulting notion of Assets in Software Engineering. We explore various types of assets, their main characteristics, such as providing inherent value. We discuss various types of value degradation and the possible implications of this on the planning, realisation, and evolution of software-intensive products and services over time. 

During the development and maintenance of software-intensive products or services, we depend on various artefacts. Some of those artefacts, we deem central to the feasibility of a project and the product's final quality. Typically, these central artefacts are referred to as assets. However, despite their central role in the software development process, little thought is yet invested into what eventually characterises as an asset, often resulting in many terms and underlying concepts being mixed and used inconsistently. A precise terminology of assets and related concepts, such as asset degradation, are crucial for setting up a new generation of cost-effective software engineering practices. In this position paper, we critically reflect upon the notion of assets in software engineering. As a starting point, we define the terminology and concepts of assets and extend the reasoning behind them. We explore assets’ characteristics and discuss what asset degradation is as well as its various types and the implications that asset degradation might bring for the planning, realisation, and evolution of software-intensive products and services over time. We aspire to contribute to a more standardised definition of assets in software engineering and foster research endeavours and their practical dissemination in a common, more unified direction. © 2022 The Authors

Context:Developing software-intensive products or services usually involves a plethora of software artefacts. Assets are artefacts intended to be used more than once and have value for organisations; examples include test cases, code, requirements, and documentation. During the development process, assets might degrade, affecting the effectiveness and efficiency of the development process. Therefore, assets are an investment that requires continuous management.

Identifying assets is the first step for their effective management. However, there is a lack of awareness of what assets and types of assets are common in software-developing organisations. Most types of assets are understudied, and their state of quality and how they degrade over time have not been well-understood.

Methods:We performed an analysis of secondary literature and a field study at five companies to investigate and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy.

Results:We present the first comprehensive, structured, yet extendable taxonomy of assets, containing 57 types of assets.

Conclusions:The taxonomy serves as a foundation for identifying assets that are relevant for an organisation and enables the study of asset management and asset degradation concepts.

Developing a software-intensive product or service can be a significant undertaking, associated with unique challenges in each project stage, from inception to development, delivery, maintenance, and evolution. Each step results in artefacts that are crucial for the project outcome, such as source-code and supporting deliverables, e.g., documentation.

Artefacts which have inherent value for the organisation are assets, and as assets, they are subject to degradation. This degradation occurs over time, as artefacts age, and can be more immediate or slowly over a period of time, similar to the concept of technical debt. One challenge with the concept of assets is that it seems not to be well-understood and generally delimited to a few types of assets (often code-based), overlooking other equally important assets. 

To bridge this gap, we have performed a study to formulate a structured taxonomy of assets. We use empirical data collected through industrial workshops and a literature review to ground the taxonomy. The taxonomy serves as foundations for concepts like asset degradation and asset management. The taxonomy can help contextualise, homogenise, extend the concept of technical debt, and serves as a conceptual framework for better identification, discussion, and utilisation of assets.

Background: The COVID-19 outbreak interrupted regular activities for over a year in many countries and resulted in a radical change in ways of working for software development companies, i.e., most software development companies switched to a forced Working-From-Home (WFH) mode. Aim: Although several studies have analysed different aspects of forced WFH mode, it is unknown whether and to what extent WFH impacted the accumulation of technical debt (TD) when developers have different ways to coordinate and communicate with peers. Method: Using the year 2019 as a baseline, we carried out an industrial case study to analyse the evolution of TD in five components that are part of a large project while WFH. As part of the data collection, we carried out a focus group with developers to explain the different patterns observed from the quantitative data analysis. Results: TD accumulated at a slower pace during WFH as compared with the working-from-office period in four components out of five. These differences were found to be statistically significant. Through a focus group, we have identified different factors that might explain the changes in TD accumulation. One of these factors is responsibility diffusion which seems to explain why TD grows faster during the WFH period in one of the components. Conclusion: The results suggest that when the ways of working change, the change between working from office and working from home does not result in an increased accumulation of TD. © 2022 IEEE.

Software development is a collaborative endeavour. Organisations that develop software assign modules to different teams, i.e., teams own their modules and are responsible for them. These modules are rarely isolated, meaning that there exist dependencies among them. Therefore, other teams might often contribute to developing modules they do not own. The contribution can be, among other types, in the form of code authorship, code review, and issue detection. This research presents a model to investigate the alignment between module ownership and contribution and the preliminary results of an industrial case study to evaluate the model in practice. Our model uses seven metrics to assess teams' contributions. Initial results suggest that the model correctly identifies misalignment between ownership and contribution. The detection of misalignment between ownership and contribution is the first step towards investigating the impact it might have on the faster accumulation of Technical Debt. © 2022 IEEE.

Code evolution, whether related to the development of new features, bug fixing, or refactoring, inevitably changes the quality of the code. One particular type of such change is the accumulation of Technical Debt (TD) resulting from sub-optimal design decisions. Traditionally, refactoring is one of the means that has been acknowledged to help to keep TD under control. Developers refactor their code to improve its maintainability and to repay TD (e.g., by removing existing code smells and anti-patterns in the source code). While the accumulation of the TD and the effect of refactoring on TD have been studied before, there is a lack of empirical evidence from industrial projects on how the different types of code changes affect the TD and whether specific refactoring operations are more effective for repaying TD. To fill this gap, we conducted an empirical study on an industrial project and investigated how Refactoring, Bug Fixing, and New Development affect the TD. We have analyzed 2, 286 commits in total to identify which activities reduced, kept the same, or even increased the TD, further delving into specific refactoring operations to assess their impact. Our results suggest that TD in the studied project is mainly introduced in the development of new features (estimated in 72.8 hours). Counterintuitively, from the commits tagged as refactoring, only 22.90% repay TD (estimated to repay 8.30 hours of the TD). Moreover, while some types of refactoring operations (e.g., Extract Method), help repaying TD, other refactoring operations (e.g., Move Class) are highly prone to introduce more TD. © 2020 IEEE.

Service-based cloud applications are software systems that continuously evolve to satisfy new user requirements and technological changes. This kind of applications also require elasticity, scalability, and high availability, which means that deployment of new functionalities or architectural adaptations to fulfill service level agreements (SLAs) should be performed while the application is in execution. Dynamic architectural reconfiguration is essential to minimize system disruptions while new or modified services are being integrated into existing cloud applications. Thus, cloud applications should be developed following principles that support dynamic reconfiguration of services, and also tools to automate these reconfigurations at runtime are needed. This paper presents an extension of a model-driven method for dynamic and incremental architecture reconfiguration of cloud services that allows developers to specify new services as software increments, and the tool to generate the implementation code for the services integration logic and the deployment and architectural reconfiguration scripts specific to the cloud environment in which the service will be deployed (e.g., Microsoft Azure). We also report the results of a quasi-experiment that empirically validate our method. It was conducted to evaluate their perceived ease of use, perceived usefulness, and perceived intention to use. The results show that the participants perceive the method to be useful, and they also expressed their intention to use the method in the future. Although further experiments must be carried out to corroborate these results, the method has proven to be a promising architectural reconfiguration process for cloud applications in the context of agile and incremental development processes.

With the growing interest of adopting agile methods in offshored process, many companies realized that the use of agile methods and practices in companies located outside the location of early adopters of agile methods may be challenging. India, the main destination of offshoring contracts, have received particular attention, due to the big cultural differences. Critical analysis of related studies suggests that impeding behaviors are mostly rooted in the hierarchical culture of Indian organizations and related management behavior of command-and-control. But what happens in distributed projects with a more empowering onshore management? In this paper, we present the findings from a multiple-case study of DevOps teams with members from a mature agile company located in Sweden and a more hierarchical offshore vendor from India. Based on two focus groups we list culturally different behaviors of offshore engineers that were reported to impede agile ways of working. Furthermore, we report the findings from surveying 36 offshore team members from five DevOps teams regarding their likely behavior in situations reported to be problematic. Our findings confirm a number of previously reported behaviors rooted in cultural differences that impede the adoption of agile ways of working when collaborating with offshore engineers. At the same time, our survey results suggest that among the five surveyed teams there were teams that succeeded with the cultural integration of the offshore team members. Finally, our findings demonstrate the importance of cultural training especially when onboarding new team members. © The Author(s) 2020.

While modern software companies strive to increase team autonomy to enable them to successfully operate the piece of software they develop and deploy, efficient ways to orchestrate the work of multiple autonomous teams working in parallel are still poorly understood. In this paper, we report how team autonomy is maintained at Spotify at scale, based on team retrospectives, interviews with team managers and archival analysis of corporate databases and work procedures. In particular, we describe how managerial authority is decentralized through various workgroups with collective authority, what compromises are made to team autonomy to ensure alignment and which team-related factors can further hinder autonomy. Our findings show that scaled autonomy at Spotify does not mean anarchy, or unlimited permissiveness. Instead, squads are expected to take responsibility for their work and coordinate, communicate and align their actions with others, and comply with a few enabling constraints. Further, squads take many decisions independently without management control or due to collective efforts that bypass formal boundary structures. Mechanisms and strategies that enable self-organization at Spotify are related to effective sharing of the codebase, achieving alignment, networking and knowledge sharing, and are described to guide other companies in their efforts to scale autonomy. © 2023 The Author(s)

Context: Agile methods in offshored projects have become increasingly popular. Yet, many companies have found that the use of agile methods in coordination with companies located outside the regions of early agile adopters remains challenging. India has received particular attention as the leading destination of offshoring contracts due to significant cultural differences between sides of such contracts. Alarming differences are primarily rooted in the hierarchical business culture of Indian organizations and related command-and-control management behavior styles. Objective: In this study, we attempt to understand whether cultural barriers persist in distributed projects in which Indian engineers work with a more empowering Swedish management, and if so, how to overcome them. The present work is an invited extension of a conference paper. Method: We performed a multiple-case study in a mature agile company located in Sweden and a more hierarchical Indian vendor. We collected data from five group interviews with a total of 34 participants and five workshops with 96 participants in five distributed DevOps teams, including 36 Indian members, whose preferred behavior in different situations we surveyed. Results: We identified twelve cultural barriers, six of which were classified as impediments to agile software development practices, and report on the manifestation of these barriers in five DevOps teams. Finally, we put forward recommendations to overcome the identified barriers and emphasize the importance of cultural training, especially when onboarding new team members. Conclusions: Our findings confirm previously reported behaviors rooted in cultural differences that impede the adoption of agile approaches in offshore collaborations, and identify new barriers not previously reported. In contrast to the existing opinion that cultural characteristics are rigid and unchanging, we found that some barriers present at the beginning of the studied collaboration disappeared over time. Many offshore members reported behaving similarly to their onshore colleagues.

In early 2020, the Covid-19 pandemic forced employees in tech companies worldwide to abruptly transition from working in offices to working from their homes. During two years of predominantly working from home, employees and managers alike formed expectations about what post-pandemic working life should look like. Many companies are experimenting with new work policies that balance employee- and manager expectations regarding where, when and how work should be done in the future. In this article, we gather experiences of the new trend of remote working based on the synthesis of 22 company-internal surveys of employee preferences for WFH, and 26 post-pandemic work policies from 17 companies and their sites, covering 12 countries in total. Our results are threefold. First, through the new work policies, all companies formally give employees more flexibility regarding working time and location. Second, there is a great variation in how much flexibility the companies are willing to yield to the employees. The paper details the different formulations that companies adopted to document the extent of permitted WFH, exceptions, relocation permits and the authorisation procedures. Third, we document a change in the psychological contract between employees and managers, where the option of working from home is converted from an exclusive perk that managers could choose to give to the few, to a core privilege that all employees feel they are entitled to. Finally, there are indications that as the companies learn and solicit feedback regarding the efficiency of the chosen strategies, we will see further developments and changes in the work policies concerning how much flexibility to work whenever and from wherever they grant. Through these findings, the paper contributes to a growing literature about the new trends emerging from the pandemic in tech companies and spells out practical implications onwards. © 2022 The Author(s)

The COVID-19 outbreak has admittedly caused interruptions to production, transportation, and mobility, therefore, having a significant impact on the global supply and demand chain's well-functioning. But what happened to companies developing digital services, such as software? How has the enforced Working-From-Home (WFH) mode impacted their ability to deliver software, if at all? This article shares our findings from monitoring the WFH during 2020 in an international software company with engineers located in Sweden, the USA, and the UK. We analyzed different aspects of productivity, such as developer job satisfaction and well-being, activity, communication and collaboration, efficiency and flow based on the archives of commit data, calendar invites, Slack communication, the internal reports of WFH experiences, and 30 interviews carried out in April/May and September 2020. We add more objective evidence to the existing COVID-19 studies the vast majority of which are based on self-reported productivity from the early months of the pandemic. We find that engineers continue committing code and carrying out their daily duties, as their routines adjust to “the new norm”. Our key message is that software engineers can work from home and quickly adjust their tactical approaches to the changes of unprecedented scale. Further, WFH has its benefits, including better work-life balance, improved flow, and improved quality of distributed meetings and events. Yet, WFH is not challenge free: not everybody feels equally productive working from home, work hours for many increased, while physical activity, socialization, pairing and opportunities to connect to unfamiliar colleagues decreased. Information sharing and meeting patterns also changed. Finally, experiences gained during the pandemic will have a lasting impact on the future of the workplace. The results of an internal company-wide survey suggest that only 9% of engineers will return to work in the office full time. Our article concludes with the InterSoft's strategy for work from anywhere (WFX), and a list of useful adjustments for a better WFH. © 2022 The Author(s)

Global software engineering has changed the way software is developed today. To address the new challenges, many universities have launched specially tailored courses to train young professionals to work in globally distributed projects. However, a mere acknowledgment of the geographic, temporal, and cultural differences does not necessarily lead to a deep understanding of the underlying practical implications. Therefore, many universities developed alternative teaching and learning activities, such as multi-university collaborative projects and small-scale simulations or games. In this article, we present a small-scale exercise that uses LEGO bricks to teach skills necessary for global work. We describe the many different interventions that could be implemented in the execution of the exercise. We had seven runs of the exercises and report our findings from executing seven runs of the exercise with the total of 104 students from five different courses in two different universities. Our results suggest that the exercise can be a valuable tool to help students dealing with troublesome knowledge associated with global software engineering and a useful complement to the courses dedicated to this subject. © 2019 Copyright is held by the owner/author(s)