Context Generative AI tools can enhance the productivity and effectiveness of software development. These tools are evolving rapidly, as are the associated risks. Therefore, software organizations adopting these tools need to understand their risks, why they occur, and how they evolve over time. Objective Previous research has highlighted risks related to using generative AI in software development; however, the underlying causes of these risks remain largely unexplored. To effectively manage these risks, we need to understand what causes them. Therefore, we examine the causal explanations behind the risks of using generative AI in software development organizations. Methods In a multi-case study of three Danish software organizations during the early stages of generative AI tool adoption, we interviewed software developers and managers within these organizations to uncover the causal explanations of risks associated with generative AI. We employed a causal mapping approach to understand and visualize the differences and similarities across software organizations’ causal explanations of risks. A year later, we returned to validate the risks and causal maps with representatives from each software organization. Results Our study shows that the software organizations exhibit circular reasoning regarding a perpetual uncertainty in the validity of AI-generated code, with the three risks: Mistrust of AI, Insufficient validation of AI output , and Insufficient/insecure AI output. They are also concerned about similar root risks, which solely cause other risks without being caused by any risks themselves, such as Lacking AI competencies . While they differed in emphasis on tail-end risks, which are understood as not causing any additional risks. Conclusion The causal mapping approach proved appropriate for showing similarities and differences in software organizations’ perceptions of risks and causal explanations related to the use of generative AI in software development. The same applies to visualizing how the emphasis on risks can change over time.

Agility is an overarching ideal for empirically-driven software development processes that embrace change in order to improve quality, economy, and simplicity. While the pursuit of Agility has held prominence in software practice and research for over two decades, user experience (UX) designers struggle to integrate their work processes with agile software development. As empirical processes are constantly evolving, so is this integration struggle for UX designers. We, therefore, present an industrial case study of how a Danish software company integrates UX design and agile software development. We conducted a case study involving (a) one iteration of individual interviews with 10 employees (four UX designers, three software developers, two project managers, and one solution architect) and (b) a follow-up iteration consisting of a workshop with 6 employees (three UX designers, two solution architects, and one project manager) two years later. We analyzed how the company's approach to integration with 'upfront design' and 'work in parallel' involve mutual adjustments as opposed to assimilation or separation of UX design and software development. Our analysis shows how integration through mutual adjustments made distinct contributions to UX designers' and software developers' pursuit of Agility. They experienced notably different work processes that still dealt effectively with change and contributed to quality, economy, or simplicity. Nevertheless, as shown from a follow-up workshop two years after our first interviews, these processes were still susceptible to integration struggles over time. We conclude that integration based on mutual adjustment potentially makes Agility for UX designers and software developers different and mutually complementary. This integration contrasts with assimilation, which potentially makes their Agility mutually indistinguishably, and with separation, which makes their Agility different and mutually competing.

Business cases have become popular as part of managing value creation in IS projects. Nevertheless, business cases are often poorly linked to value creation activities and organizations struggle to develop business cases that are useful and express more than simple cost savings. This action research study seeks to improve the usefulness of business cases in IS projects. We used collaborative action research with Danish municipalities to improve their practices when developing and using business cases and to change their perceptions of what constitutes a good business case that is useful during implementation and value creation. This article presents lessons learned from our action research, lessons that we incorporated into a business case method and subsequently evaluated with IS managers. There are three lessons on (1) improving the content of business cases, (2) how to develop business cases, and (3) the use of business cases in subsequent value creation. These lessons summarize our findings and the contributions are that we in the business case method propose to (1) include minimal contents, (2) develop social commitment, and (3) structure for dynamic use during value creation. We discuss the lessons and contributions related to research on IS business cases and value creation.