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.

Although the COVID-19 pandemic is behind us, the seminal challenge for agile teams has not gone away, as “Work-From-Home (WFH) is here to stay”. Despite a wealth of literature documenting the challenges of applying agile methods in remote environments, practical guidance for overcoming these challenges remains limited. Furthermore, systematic meta-guidelines to help practitioners develop tailored, context-specific solutions are largely absent. This article reports on an Action Research project conducted at S&P Global 18 months after the company’s transition to a WFH model. The project aimed to evaluate existing adaptations to remote work, identify persistent issues, and develop strategies to address them. Our investigation revealed that while ad-hoc solutions — such as virtualizing Scrum ceremonies and shifting informal in-person conversations to Slack channels — enabled work continuity during the pandemic, they proved insufficient for tackling more complex challenges. Intriguingly, only two ongoing issues stemmed from misalignments between Scrum and remote settings, while the remainder were rooted in flawed Scrum implementation. With our guidance, the participating team not only rediscovered the “Inspect and Adapt” principle but also mastered a systematic approach to method tailoring, enabling them to devise measures that effectively resolved most of their issues. Our study reinforces prior findings indicating the applicability of Scrum beyond its traditional “home ground”, while also highlighting the need for remote teams to exhibit even greater discipline in adhering to the Scrum framework to navigate the additional challenges of remote work. We also observed a heightened necessity for more comprehensive documentation in remote settings to compensate for limited immediate access to colleague assistance, which consequently restricts knowledge sharing. Finally, the structured approach we employed offers valuable guidance for software companies seeking to identify and address operational inefficiencies in both remote and hybrid work environments. • Most issues stem from flawed Scrum implementation, not its mismatch with remote work. • Remote Scrum reveals hidden dysfunctions not apparent in traditional office settings. • Remote teams need more strategic documentation to enhance knowledge sharing. • Tailored Scrum with collaboration tools excels remotely, defying collocation assumptions. • Action Research guides practitioners to systematically refine their practices.

ABSTRACT Context Generative artificial intelligence (GenAI) tools have become increasingly prevalent in software development, offering assistance to various managerial and technical project activities. Notable examples of these tools include OpenAI's ChatGPT, GitHub Copilot, and Amazon CodeWhisperer. Objective Although many recent publications have explored and evaluated the application of GenAI, a comprehensive understanding of the current development, applications, limitations, and open challenges remains unclear to many. Particularly, we do not have an overall picture of the current state of GenAI technology in practical software engineering usage scenarios. Method We conducted a literature review and focus groups for a duration of five months to develop a research agenda on GenAI for software engineering. Results We identified 78 open research questions (RQs) in 11 areas of software engineering. Our results show that it is possible to explore the adoption of GenAI in partial automation and support decision‐making in all software development activities. While the current literature is skewed toward software implementation, quality assurance and software maintenance, other areas, such as requirements engineering, software design, and software engineering education, would need further research attention. Common considerations when implementing GenAI include industry‐level assessment, dependability and accuracy, data accessibility, transparency, and sustainability aspects associated with the technology. Conclusions GenAI is bringing significant changes to the field of software engineering. Nevertheless, the state of research on the topic still remains immature. We believe that this research agenda holds significance and practical value for informing both researchers and practitioners about current applications and guiding future research.

Abstract Agile transformations have been a significant challenge since the beginning of the agile movement, with numerous researchers and practitioners suggesting various structured approaches and guidelines. The Kanban Maturity Model (KMM) is a relatively new approach that focuses on assessing the current maturity level of an organisation, with an emphasis on a spectrum of Kanban practices. This paper presents the initial results of applying the KMM as a guide for subsequent steps in Kanban implementation and agile transformation. The exploratory case study describes the application of the KMM in the agile transformation of a software development team within a midsize organisation. Despite previous unsuccessful attempts to implement Scrum, the adoption of KMM facilitated a rapid and successful implementation of the Kanban Method. Within three months, the team’s throughput tripled, and the quality of the developed software improved significantly. The results suggest that the KMM can be successfully used as an effective guideline for agile transformation of software development teams.

Abstract After the COVID-19 breakout, agile teams found themselves in situations that “pure agilists” and textbooks on agile methods had preferred to ignore. Whereas agile mindsets helped them to quickly shift to remote work, mere virtualization of agile practices often proved insufficient, and several challenges emerged. This paper reports on an Action Research project carried out in Lufthansa Systems Poland with the aim of (1) revisiting their ad-hoc actions to adapt to remote work; and (2) elaborating systematic solutions to maintain efficiency in such a setting. With our assistance, the participating teams found measures to mitigate issues posed by the new work environment. They devised an inter-team communication model to improve the effectiveness of information exchange that had declined in the absence of spontaneous, face-to-face communication. Moreover, they employed several other mitigation strategies, including working at least one day per week in the office, keeping webcams on during online meetings, and recapping meetings at the end of a session. Our study largely supports previous findings indicating that Scrum can be effectively applied beyond its comfort zone but also suggests that for adaptations to be successful and comprehensive, they should be developed in a structured manner.

Abstract Despite a wide range of scaling frameworks available, large‐scale agile transformations are not straightforward undertakings. Few organizations have structures in place that fit the predefined workflows – while once one applies an off‐the‐shelf framework outside of its prescribed process, guidance quickly runs out. In this paper, we demonstrate how to instantiate a method configuration process using a lightweight experimental approach embedded in Action Research cycles. The proposed approach was developed to assist practitioners working on a multiple‐team project at Intel Technology Poland to find the right practices to continue their Nexus‐based transformation and integrate their in‐house method into the already established company structures, processes, and routines. In particular, it enabled identifying a series of challenges with scaled practices and coping with those. The challenges ranged from logistical problems, through poor availability of the Product Owner, to lackluster knowledge transfer and a wide array of communication/coordination issues at meetings. The study broadens the current body of knowledge within technology management and the scaled agile method‐tailoring domain. It indicates potential corrective actions that may be taken advantage of by entities that are not inclined, due to organizational constraints, to directly implement an off‐the‐shelf framework. Furthermore, our study demonstrates that a gradual transition to large‐scale agile at the project level (1) is possible with the preservation of traditional command‐and‐control management practices; (2) requires neither middle management involvement nor upfront investment; and (3) does not need to disrupt the continuous delivery of the product.

In today's fast-paced world of rapid technological change, software development teams need to constantly revise their work practices. Not surprisingly, regular reflection on how to become more effective is perceived as one of the most important principles of Agile Software Development. Nevertheless, running an effective and enjoyable retrospective meeting is still a challenge in real environments. As reported by several studies, the Sprint Retrospective is an agile practice most likely to be implemented improperly or sacrificed when teams perform under pressure to deliver. To facilitate the implementation of the practice, some agile coaches have proposed to set up retrospective meetings in the form of retrospective games. However, there has been little research-based evidence to support the positive effects of retrospective games. Our aim is to investigate whether the adoption of retrospective games can improve retrospective meetings in general and lead to positive societal outcomes. In this paper, we report on an Action Research project in which we implemented six retrospective games in six Scrum teams that had experienced common retrospective problems. The received feedback indicates that the approach helped the teams to mitigate many of the "accidental difficulties" pertaining to the Sprint Retrospective, such as lack of structure, dullness, too many complaints, or unequal participation and made the meetings more productive to some degree. Moreover, depending on their individual preferences, different participants perceived different games as having a positive impact on their communication, motivation-and-involvement, and/or creativity, even though there were others, less numerous, who had an opposite view. The advantages and disadvantages of each game as well as eight lessons learned are presented in the paper.

Abstract This article reports on a domain‐specific software development venture at Nordea. We explore organizational constraints, challenges, and corrective actions undertaken when scaling the agile development approach of their Core Banking Platform program. The fit and required customizations of the rather complex and rigid SAFe framework in a policy‐heavy financial institution are audited against the organic growth of the program. In a qualitative study with three cycles using the Action Research method, both organizational and technical restrictions were tackled jointly with the company employees. Thirty‐four potential solutions were developed—some of which turned out to be dead‐ends. Ultimately, the effectiveness of prior recommendations was tested in a highly challenging implementation environment, and the list of guidelines was extended. We discovered several meeting and collaboration schemes that are not fully aligned with previous reports.

With the advances in systems-on-a-chip technologies, there is a growing demand to deploy intelligent vision systems on low-cost microcomputers. To address this challenge, much of the recent research has focused on reducing the model size and computational complexity of contemporary convolutional neural networks (CNNs). The state-of-the-art lightweight CNN is MobileNetV3. However, it was designed to achieve a good trade-off between accuracy and latency on a single large core of a Google Pixel 1 smartphone. Accordingly, MobileNetV3 is not optimized for platforms with different hardware characteristics and its predecessors may perform better for a given target platform. The aim of this paper is twofold: 1) to analyze the performance of different compact CNNs on Raspberry Pi 4; 2) to manually adapted the most promising models to better utilize the Raspberry Pi 4 hardware. After exploring a number of modifications, we present a new CNN architecture, namely MobileNetV3-Small-Pi, which is 36% faster and slightly more accurate on ImageNet classification compared to the baseline MobileNetV3-Small.

In agile software development, where great emphasis is put on effective informal communication involving diverse stakeholders, success depends on human and social factors. Not surprisingly, the Agile Manifesto advocates principles and values such as “individuals and interactions over processes and tools”, “focus on the customer”, “collaborate regularly”, “communicate face-to-face within the team” and “have regular team introspection”. However, agile methodologies have hardly provided any tools or techniques that aid the human side of software development. Additionally, more and more research suggests that customers no longer should be viewed as a passive source of information but need to be engaged in envisioning future business practice, discovering opportunities, and shaping solutions. To deal with these challenges, we propose a framework for extending Scrum with 9 collaborative games. Collaborative games refer to several structured techniques inspired by game play and designed to facilitate collaboration, foster customer involvement, and stimulate creative thinking. The feedback received from a Scrum team that leveraged our framework in two commercial projects, indicates that the adopted collaborative games: (1) make customers more willing to attend the meeting; (2) foster stakeholders’ commitment; and (3) produce better results than the standard approach

Effective collaboration and interaction among the development team and between the team and the customer as well as proactive attitude in initiating and implementing improvements play vital roles in the success of agile projects.The challenge is how to address these social aspects since neither the Agile Manifesto nor the Scrum Guide specify techniques that aid the human side of software development.To fill this gap, we developed a web portal which provides 8 collaborative games to be used in agile software development.The feedback received from a Scrum team, who leveraged the games in an industrial project conducted in OKE Poland, indicates that our approach improves participants' communication, motivation, commitment, and creativity.

Since its inception in 1996, aspect-oriented programming (AOP) has been believed to reduce the effort required to maintain software systems by replacing cross-cutting code with aspects. However, little convincing empirical evidence exists to support this claim, while several studies suggest that AOP brings new obstacles to maintainability. This paper discusses two controlled experiments conducted to evaluate the impact of AspectJ (the most mature and popular aspect-oriented programming language) versus Java on software evolvability. We consider evolvability as the ease with which a software system can be updated to fulfill new requirements. Since a minor language was compared to the mainstream, the experiments were designed so as to anticipate that the participants were much more experienced in one of the treatments. The first experiment was performed on 35 student subjects who were asked to comprehend either Java or AspectJ implementation of the same system, and perform the corresponding comprehension tasks. Participants of both groups achieved a high rate of correct answers without a statistically significant difference between the groups. Nevertheless, the Java group significantly outperformed the AspectJ group with respect to the average completion time. In the second experiment, 24 student subjects were asked to implement (in a non-invasive way) two extension scenarios to the system that they had already known. Each subject evolved either the Java version using Java or the AspectJ version using AspectJ. We found out that a typical AspectJ programmer needs significantly fewer atomic changes to implement the change scenarios than a typical Java programmer, but we did not observe a significant difference in completion time. The overall result indicates that AspectJ has a different effect on two sub-characteristics of the evolvability: understandability and changeability. While AspectJ decreases the former, it improves one aspect of the latter.

According to the textbook [23], Scrum exists only in its entirety, where every component is essential to Scrum's success.However, in many organizational environments some of the components are omitted or modified in a way that is not aligned with the Scrum guidelines.Usually, such deviations result in missing the full benefits of Scrum [24].Thereby, a Scrum process should be frequently inspected and any deviations should be corrected [23].In this paper, we report on an Action Research project conducted in Intel Technology Poland to revise the work practices related to the Retrospective.During the focus group discussion in the company, retrospectives were generally judged ineffective because "the same things are discussed over and over".To cope with this challenge, we revitalized retrospectives by adopting collaborative games.The feedback received from three Scrum teams indicates that our approach improved participants' creativity, involvement, and communication, and produced better results than the standard retrospective.

The crucial element of any agile project is people.Not surprisingly, principles and values such as "Respect for people", "Communication and Collaboration", "Lead using a team approach", and "Learn and improve continuously" are an integral part of Open Kanban.However, Open Kanban has not provided any tools or techniques to aid the human side of software development.Moreover, as a Lean initiative, it is not as comprehensively defined process as Scrum or XP.Accordingly, inexperienced Kanban teams may feel a bit lost.To deal with these challenges, we propose an extension to Open Kanban, which contains a set of 12 collaborative games.The feedback received from three Kanban teams who leveraged our extension in commercial projects, indicates that the adopted games improved participants' communication, commitment, motivation and creativity.

hardest single part of building a software system is deciding precisely what to build (Brooks, 1987). Faulty requirements analysis is a major reason for project failure or unsatisfactory information systems that do not fulfill business needs. Although it has been long recognized that system requirements can only be understood within the context of the business processes and business modeling has become the initial phase of most software processes, the transition between business modeling and requirements gathering is still a challenge for research. Moreover, existing work in this area tends to introduce accidental difficulties. This paper reports the results of an action research conducted for elaborating a Business-Oriented approach to Requirements Elicitation. Our approach integrates Requirements Engineering with Business Process Engineering and derives system requirements based on business process models. This ensures that system requirements meet real business needs. The proposed approach is illustrated by a real-world example.