Abstract Context: The rapid emergence of generative AI (GenAI) tools has begun to reshape software engineering practice. Yet, their adoption within agile environments remains underexplored. Objective: This study investigates how agile practitioners adopt GenAI tools in real-world organizational contexts, focusing on regulatory conditions, role-specific use cases, benefits, and barriers. Method: An exploratory multiple case study was conducted in three German organizations, involving 17 semi-structured interviews and document analysis. A cross-case thematic analysis was applied to identify GenAI adoption patterns. Results: Findings reveal that GenAI is primarily used for creative tasks, documentation, and code assistance. Benefits include efficiency gains and enhanced creativity, while barriers relate to data privacy, validation effort, and lack of governance. Using the Technology-Organization-Environment (TOE) framework, we find that these barriers stem from misalignments across the three dimensions. Regulatory pressures are often translated into policies without accounting for actual usage patterns or organizational constraints, leading to systematic policy-practice gaps and shadow IT behavior. Conclusion: GenAI offers significant potential to augment agile roles but requires alignment across TOE dimensions, including pragmatic policies, data protection measures, and user training to ensure responsible and effective integration.

ABSTRACT This position paper investigates the transformative impact of generative artificial intelligence (GenAI) on Agile roles. Focusing on the product owner, developer, and scrum master, we analyze how GenAI redefines traditional tasks, encouraging a shift towards more strategic and creative functions. Through practical experience, we illustrate AI's role in enhancing Agile processes, its practices and emphasize the need for Agile practitioners to integrate AI understanding. These results highlight the balance between GenAI's efficiencies and Agile's human‐centric principles, proposing research directions for AI‐enriched Agile practices that promise to drive innovation and maintain the agility in a technologically progressive era.

Abstract Many smaller companies cannot afford the time and effort to change their development processes all at once. In some cases, companies are not aware of the fact that many aspects of agile development are already in place. The aim of this work was to evaluate if an evolutionary transition to agile software development is suitable for small companies. We conducted a case study with a small company to start their step‐by‐step agile transition. Initially, three agile software development practices were introduced. Based on the assessment of improvements, the transition continued with three Kanban practices. Experiences with the improvement process and the selected practices were elicited by means of qualitative interviews for data collection. Our case study reports details on the implementation of the first practices as well as the way the resulting agile transition has taken so far. The positive experiences reported by all employees during the agile transition indicate that an evolutionary transition is suitable for small companies. The experiences concerning the transition process and the positive effects of the selected practices motivate practitioners to start their own agile transition.

Abstract The emergence of agile methods and practices has not only changed the development processes but might also have affected how companies conduct software process improvement (SPI). Through a set of complementary studies, we aim to understand how SPI has changed in times of agile software development. Specifically, we aim (a) to identify and characterize the set of publications that connect elements of agility to SPI, (b) to explore to which extent agile methods/practices have been used in the context of SPI, and (c) to understand whether the topics addressed in the literature are relevant and useful for industry professionals. To study these questions, we conducted an in‐depth analysis of the literature identified in a previous mapping study, an interview study, and an analysis of the responses given by industry professionals to SPI‐related questions stemming from an independently conducted survey study. Regarding the first question, we identified 55 publications that focus on both SPI and agility of which 48 present and discuss how agile methods/practices are used to steer SPI initiatives. Regarding the second question, we found that the two most frequently mentioned agile methods in the context of SPI are Scrum and Extreme Programming (XP), while the most frequently mentioned agile practices are integrate often, test‐first, daily meeting, pair programming, retrospective, on‐site customer, and product backlog. Regarding the third question, we found that a majority of the interviewed and surveyed industry professionals see SPI as a continuous activity. They agree with the agile SPI literature that agile methods/practices play an important role in SPI activities but that the importance given to specific agile methods/practices does not always coincide with the frequency with which these methods/practices are mentioned in the literature.

Context: Many smaller companies do not have time and effort to change their development processes at a time. In some cases, companies are not aware of the fact that many aspects of agile development are already in place. Objective: For this reason, only introducing a small set of agile practices in our SME-company case, namely User Stories, Definition of Done, and Definition of Ready, was our initial starting point for the evolutionary agile transition. Method: The introduction of these three practices was performed within a case study, assessing the results with qualitative interviews. Results: Our case study reports on the implementation of the selected practices and shows their benefits, highlighting the importance of User Stories as a central agile artefact. Conclusions: Based on the positive experiences made during the implementation of these agile practices, all employees of the SME opened up to proceed with the agile transition.

Abstract Agile is the widespread software development approach. But many projects are still working with traditional methods. In addition, non-technical business units continue working in traditional ways. Thus, problems arise on the interface of agile and traditional due to their fundamental differences. To prevent potential problems, one must be aware of the existing interfaces and common pitfalls. Based on a literature search and workshops, we identified existing interfaces, collected and grouped problems. We present the identified problems and propose a matrix that facilitates classification of interface problems. This matrix can be used to identify and classify more problems as well as understanding and preventing problems on the interface of agile and traditional.

Abstract Background Agile development shows benefits for software‐developing companies, eg, shorter time to market or stronger customer connections. Nonetheless, agile methods and practices are most often adapted to a specific context. Especially in regulated domains such as automotive, avionics, or medical, domain‐specific constraints need to be considered, and hence, Agile is often used only partially or not at all. Objective The goal of this study was to identify the state of the practice in using agile development as part of the development process in regulated embedded domains. Method We conducted a study using a combination of a series of interviews and an online questionnaire as data collection methods. Results The responses of 50 participants showed that Agile, mostly in the form of an adapted form of Scrum, has already arrived in those domains, but mainly in noncritical projects and/or early project phases. This means there is further improvement potential, which was also confirmed by the participants regarding future usage. Conclusions The results of our state‐of‐the‐practice study provide a good stage for future work, especially for new approaches bringing more “agility” into regulated embedded domains.

Context: The validity of survey-based research depends on, amongst other considerations, the number and validity of obtained data points. As with any empirical study that involves practitioners, collecting data via surveys is difficult. Objectives: We report our experiences derived while conducting an industry survey on the impact of agile practices on software process quality. Method: After unsuccessfully trying to collect data with an online questionnaire, we used an interactive approach with posters at practitioners-focussed software engineering community events to aid data collection. Results: We present a list of lessons learnt. In particular, the poster-based data collection approach provided utility, for both gathering a large amount of responses and facilitating follow-up interactions with study participants. Conclusion: Our experiences in this work may help those facing challenges associated with obtaining responses from practitioners through the use of potentially complex questionnaires.

[Background] The effort required to systematically collect historical data is not always allocable in agile processes and historical data management is usually delegated to the developers' experience, who need to remember previous project details. However, even if well trained, developers cannot precisely remember a huge number of details, resulting in wrong decisions being made during the development process. [Aims] The goal of this paper is to operationalize the Experience Factory in an agile way, i.e., defining a strategy for collecting historical project data using an agile approach. [Method] We provide a mechanism for understanding whether a measure must be collected or not, based on the Return on Invested Time (ROIT). In order to validate this approach, we instantiated the factory with an exploratory case study, comparing four projects that did not use our approach with one project that used it after 12 weeks out of 37 and two projects that used it from the beginning. [Results] The proposed approach helps developers to constantly improve their estimation accuracy with a very positive ROIT of the collected measure. [Conclusions] From this first experience, we can conclude that the Experience Factory can be applied effectively to agile processes, supporting developers in improving their performance and reducing potential decision mistakes.

In the automotive domain, Automotive SPICE® is a common requirement for software and system development. Most automotive companies face the problem of complying with this model, especially, when dealing with agile development in order to benefit from advantages, such as higher customer collaboration or faster development. This paper describes the evaluation of how agile practices support Automotive SPICE requirements, based on literature reviews and expert opinion and including 772 mappings. 103 of 155 agile practices including Scrum and XP were used to cover 173 of 185 Automotive SPICE requirements (base practices and work products). Most Automotive SPICE base practices are supported (96%), while there is less support for work products (87%). The results are coherent with existing more high-level mappings but show more details. These results enable companies to benefit from agile without compromising Automotive SPICE conformity.

A software process is the game plan to organize project teams and run projects. Yet, it still is a challenge to select the appropriate development approach for the respective context. A multitude of development approaches compete for the users' favor, but there is no silver bullet serving all possible setups. Moreover, recent research as well as experience from practice shows companies utilizing different development approaches to assemble the best-fitting approach for the respective company: a more traditional process provides the basic framework to serve the organization, while project teams embody this framework with more agile (and/or lean) practices to keep their flexibility. The first HELENA workshop aims to bring together the community to discuss recent findings and to steer future work.

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.

Since software became a major part of the car, we were interested in identifying which agile practices are used and adapted at Bosch automotive. Therefore, we conducted a multi-case study with nine interviews from five Bosch projects. Our results showed a strong focus on Scrum. Most of the Scrum practices are adapted due to the specific project context. Practices from other agile methods, e.g. XP, are used and adapted as well. We further collected the benefits of the practices, most often resulting in improved transparency and planning. The results are used to support automotive projects in selecting and applying agile practices according to their specific process improvement goals.

Abstract It is commonly known that software or system development processes are very important for getting a high‐quality product. Such processes can be described in many different ways, from textual documents to existing modeling notations. Before dealing with the overall goal of improving the description of development processes, this paper evaluates the current state of practice regarding process descriptions and reasons for that. A major focus is on the degree of formality. Based on an interview guideline, a series of 12 interviews was conducted in German companies of different sizes. The results were analyzed to come up with the current usage of and need for software process models or descriptions. In general, our results confirm the literature statement that in industrial practice the majority of processes descriptions are detailed but rather focus on informal descriptions than formal notations or models. Nevertheless, they use semiformal process descriptions containing different graphical, table‐based, or structured‐text elements for representation. It is interesting that even if companies do not want to use formal models; they would like to have their advantages and even often have the detailed information necessary for formal models. Overall, our findings provide evidence on the state of practice regarding usage of process descriptions and models and show the need for future work in this area.

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.

Context: It is well known that in software engineering, software or system development processes are very important for getting a high quality product. Such processes can be described in many different ways, from textual documents to existing modeling notations. Objective: Before dealing with the overall goal of improving the description of development processes, this paper evaluates what process descriptions look like in practice and why they look like they do, with special focus on the degree of formality. Method: Based on a structured, semi-formal interview guideline with open and closed questions, a series of twelve interviews was conducted in German companies of different sizes (from ten to several thousand employees). The interview results were used for an analysis to come up with findings regarding the current usage of and need for software process models or descriptions. Results: In general, our results confirm the literature statement that in industrial practice the majority of processes focus on description rather than using formal notations or models. Nevertheless, they use semi-formal process descriptions containing different graphical, table-based, or structured-text elements for representation. Conclusions: It is interesting that even if companies do not want to use formal models, they would like to have the advantages offered by them. Our findings provide evidence of the state of the practice regarding usage and show the need for future work in this area of describing and modeling development processes.

Background: Technology transfer is one key to the success of research projects, especially in Software Engineering, where the (practical) impact of the outcome may depend not only on the reliability and feasibility of technologies, but also on their applicability to industrial settings. However, there is limited knowledge on the current state of practice and how to assess the success of technology transfer. Objective: We aim at elaborating a set of hypotheses on how technology transfer takes place in Software Engineering research projects. Method: We designed an exploratory survey with the participants of two large research projects in Germany, which involve both industrial and academic partners in the area of model driven development for embedded systems. Results: Base on the extracted respondents answers of this survey, we defined a resulting theory which is based on the following set of main hypothesis: Most of the technologies developed in research projects are not mature enough for a direct application, but need post-project customisation to fit the industrial contexts (H1). Common models that represent technology transfer as a transaction of an object from a transferor to a transferee does not fit industrial reality (H2). Additionally, technology transfer takes place without an explicit process (H3). Regarding transfer mediums, most used mediums are human-intensive (H5) and industry organisations gain new knowledge mainly within their own confines (H4). Finally the motivations that drive the transfer in industry and academia are heterogenous (H6). Conclusions: From the theoretical perspective, this theory and set of hypotheses extracted from the survey results will be further explored and tested in different follow-up activities. This initial set, however, already may serve as a basis for independent assessments from other researchers to collaboratively shed light on a how technology transfer takes place in Software Engineering research projects, which are the barriers, and how to improve the transfer into practice. From the practical perspective, our results may be used as a basis for an evaluation framework for the transfer of the developed technologies in our projects. This would also help companies in getting new developed technologies transfer easier to their specific context.

Background: Successful transfer of the results of research projects into practice is of great interest to all project participants. It can be assumed that different transfer mediums fulfill technology transfer (TT) with different levels of success and that they are impaired by different kinds of barriers. Objective: The goal of this study is to gain a better understanding about the different mediums used for TT in software engineering, and to identify barriers weakening the success of the application of such mediums. Method: We conducted an exploratory study implemented by a survey in the context of a German research project with a broad range of used mediums. Results: The main reported barriers were low expectations of usefulness, no awareness of existence, lack of resources, or inadequateness in terms of outdated material or being in an immature state. Conclusions: We interpreted our results as symptoms of a lack of a dissemination plan in the project. Further work will be needed to explore the implications for the transfer of research results (knowledge and techniques) to practice.

Agile software development has become well known to the community and is nowadays frequently used for the development of different kinds of software systems. Agile methods are widely spread and often adapted to the context-specific needs. The adaptations constitute reductions and/or extensions of agile practices. Yet, we have limited knowledge about the impact of some of the individual practices, which is crucial to justify organizational changes. To systemize the knowledge of the impact of agile practices, we launch this workshop and invite researchers and practitioners to work on a documenting and accumulating their experiences in a knowledge base.

Because agile development has become more important in software engineering in recent years, many companies want to become agile. One way to do so is context-specific improvement, preferably performed by selecting the right agile practices and integrating them into the current software development process. For making an appropriate selection, the impact on the improvement goals needs to be known. Therefore, the idea is to build an overall model that includes the impact of at least the most commonly used agile practices. This impact model is mainly built on these agile practices, on various impact characteristics, and on their connections. A larger example of some practices and their (possible) impact characteristics is presented. Additionally, the Agile Capability Analysis is introduced as an example application scenario of the model. The Agile Practices Impact Model presented in this paper could support context-specific integration of agility into any current development process. Nonetheless, the model needs to be filled with existing evidence.

Software process improvement (SPI) is around for decades: frameworks are proposed, success factors are studied, and experiences have been reported. However, the sheer mass of concepts, approaches, and standards published over the years overwhelms practitioners as well as researchers. What is out there? Are there new emerging approaches? What are open issues? Still, we struggle to answer the question for what is the current state of SPI and related research? In this paper, we present initial results from a systematic mapping study to shed light on the field of SPI and to draw conclusions for future research directions. An analysis of 635 publications draws a big picture of SPI-related research of the past 25 years. Our study shows a high number of solution proposals, experience reports, and secondary studies, but only few theories. In particular, standard SPI models like CMMI and ISO/IEC 15504 are analyzed, enhanced, and evaluated for applicability, whereas these standards are critically discussed from the perspective of SPI in small-to-medium-sized companies, which leads to new specialized frameworks. Furthermore, we find a growing interest in success factors to aid companies in conducting SPI.

Background: Agile software development has been increasingly adopted during the last two decades. Nonetheless, many studies show that using agile methods as defined in the literature does not work very well. Thus, companies adapt these methods by just using parts of them (called agile practices). Objective: The goal of the literature study was to understand which agile practices are used in industry under different circumstances, such as different project types, domains, or processes. Method: We conducted a mapping study of empirical studies using agile practices in industry. The search strategy identified 1110 studies, of which 24 studies including 68 projects were analyzed. Results: The results of this study show that there are practices that are used more often and that the domain and the process also influence the application of different practices. Additionally, the findings confirm the assumption of Ken Schwaber that in most cases, agile methods are not used "completely" but that rather certain practices are adopted. Conclusions: Our results can be used by researchers to get a better idea of where and how to follow up research as well as by practitioners to get a better idea of which practices fit their needs and which are used by others. Therefore, our contribution increases the body of knowledge in agile practices usage.

Background: The mobility domains are moving towards the adoption of multicore technology. Appropriate methods, techniques, and tools need to be developed or adapted in order to fulfill the existing requirements. This is a case for design space exploration methods and tools. Objective: Our goal was to understand the importance of different design space exploration goals with respect to their relevance, frequency of use, and tool support required in the development of multicore systems from the point of view of the ARAMiS project members. Our aim was to use the results to guide further work in the project. Method: We conducted a survey regarding the current state of the art in design space exploration in industry and research and collected the expectations of project members regarding design space exploration goals. Results: The results show that design space exploration is an important topic in industry as well as in research. It is used very often with different important goals to optimize the system. Conclusions: Current tools provide only partial solutions for design space exploration. Our results can be used for improving them and guiding their development according to the priorities explained in this contribution.

Background: Particularly during and after research projects, technology transfer into practice plays an important role for academia to get technologies into use and for industry to improve their development. Objective: Our goal was to gain more and current knowledge about how technology transfer from software engineering (SE) research into industrial practice is accomplished best and how to measure the effectiveness of this transfer. Method: We conducted a study in the context of two German research projects, covering many different organizations from industry and academia. Results: This paper presents the design of the study and the survey performed. After introducing the concept of technology transfer we used and adapted, we present preliminary results. Conclusions: We observed that traditional means such as meetings or workshops are still the most widely used mediums for technology transfer in SE. We also discovered that, even though the duration of transfer depends on the object being transferred, the average duration is three years, which is far less than previously published (~18 years).

Context: In the context of the research and development project ARAMiS, multiple partners from research and industry are collaborating in the development of new methods and technologies in the field of multicore systems. Goal: We designed and executed studies for evaluating the results of the ARAMiS sub-project responsible for requirements engineering: an artifact-based requirements engineering approach, its tooling, and a cross-domain scenario. Method: This evaluation was performed along with the dissemination of the results in the project. The evaluation included two studies aimed at collecting the opinions of the project participants regarding the requirements engineering results from the viewpoints of industry and research. Results: The mainly positive results showed us that the different parts of the requirements engineering approach in this project are being accepted. Conclusions: Nonetheless, especially the results for the scenario revealed some weaknesses, such as the so-called "ARAMiS gap", i.e., a gap between the high-level requirements engineering artifacts and the detailed engineering artifacts.