Search

Context: Organizations opt for continuous delivery of incremental updates to deal with uncertainty and minimize waste. However, applying continuous engineering (CSE) practices requires a continuous feedback loop with input from customers and end-users. Challenges: It becomes increasingly challenging to apply traditional requirements elicitation and validation techniques with ever-shrinking software delivery cycles. At the same time, frequent deliveries generate an abundance of usage data and telemetry informing engineering teams of end-user behavior. The literature describing how practitioners work with user feedback in CSE, is limited. Objectives: We aim to explore the state of practice related to utilization of user feedback in CSE. Specifically, what practices are used, how, and the shortcomings of these practices. Method: We conduct a qualitative survey and report analysis from 21 interviews in 13 product development companies. We apply thematic and cross-case analysis to interpret the data. Results: Based on our earlier work we suggest a conceptual model of how user feedback is utilized in CSE. We further report the identified challenges with the continuous collection and analysis of user feedback and identify implications for practice. Conclusions: Companies use a combination of qualitative and quantitative methods to infer end-user preferences. At the same time, continuous collection, analysis, interpretation, and use of data in decisions are problematic. The challenges pertain to selecting the right metrics and analysis techniques, resource allocation, and difficulties in accessing vaguely defined user groups. Our advice to practitioners in CSE is to ensure sufficient resources and effort for interpretation of the feedback, which can be facilitated by telemetry dashboards., Comment: arXiv admin comment: This version has been removed by arXiv administrators as the submitter did not have the rights to agree to the license at the time of submission

Pair programming (PP) has been a widespread practice for decades and is known for facilitating knowledge exchange and improving the quality of software. Many agilists advocated the importance of collocation, face-to-face interaction, and physical artifacts incorporated in the shared workspace when pairing. After a long period of forced work-from-home, many knowledge workers prefer to work remotely two or three days per week, which is affecting practices such as PP. In this revelatory single-case study, we aimed to understand how PP is practiced during hybrid work when team members alternate between on-site days and working from home. We collected qualitative and quantitative data through 11 semi-structured interviews, observations, feedback sessions, and self-reported surveys. The interviewees were members of an agile software development team in a Norwegian fintech company. The results presented in this paper indicate that PP can be practiced through on-site, remote, and mixed sessions, where the mixed mode seems to be the least advantageous. The findings highlight the importance of adapting the work environment to suit individual work mode preferences when it comes to PP. In the future, we will build on these findings to explore PP in other teams and organizations practicing hybrid work.

Context: Requirements elicitation is an essential activity to ensure that systems provide the necessary functionality to users, and that they are fit for purpose. In addition to traditional `reductionist' techniques, the use of observations and ethnography-style techniques have been proposed to identify requirements. Research Problem: One frequently heard issue with observational techniques is that they are costly to use, as developers would lose considerable time to partake, and also depend on luck in identifying requirements. Very few experience reports exist to evaluate observational techniques in practice. Results: In this experience report, we draw on several data sources, covering insights from both developers and users. The data were collected through 9 interviews with users and developers, and over 80 hours of observation of prospective users in the maritime domain. We capture `knowns' and `unknowns' from both developers and users, and highlight the importance of observational studies. Contribution: While observational techniques are costly to use, we conclude that essential information is uncovered, which is key for developers to understand system users and their concerns., Comment: Accepted to the International Working Conference on Requirements Engineering: Foundation for Software Quality. Springer, Cham, 2023. Barcelona, 17.-20. April

Psychological safety is a precondition for learning and success in software teams. Companies such as SavingsBank, which is discussed in this article, have developed good practices to facilitate psychological safety, most of which depend on face-to-face interaction. However, what happens to psychological safety when working remotely? In this article, we explore how Norwegian software developers experienced pandemic and post-pandemic remote work and describe simple behaviors and attitudes related to psychological safety. We pay special attention to the hybrid work mode, in which team members alternate days in the office with days working from home. Our key takeaway is that spontaneous interaction in the office facilitates psychological safety, while remote work increases the thresholds for both spontaneous interaction and psychological safety. We recommend that software teams synchronize their office presence to increase chances for spontaneous interaction in the office while benefitting from focused work while at home.

Although the pandemic times of the world-wide forced working from home seem to be in the past, many knowledge workers choose to continue working predominantly from home as a partial or permanent practice. Related studies show that employees of companies from various industries, diverse in size and location, prefer to alter working in the office with working at home, coined as hybrid or flexible working arrangements. As a result, the post-pandemic times are associated with empty offices, confused managers and organizational leaders not knowing what to do with the often-expensive rental contracts. In this paper, we investigate the employee presence in the offices in two software companies and dive deeper into the reasons behind the preferences to work remotely, practices that help to attract employees back into the offices and, in cases when this is not possible, the ways companies can repurpose the office space for the future needs of their employees. The latter are based on the qualitative analysis of interviews and survey responses. Our findings suggest that since the fall 2021 the offices were half-empty and that, on average, the daily office presence varies between 15-30%. The reasons for working remotely include behavioural and practical motivations, as well as factors related to office equipment and facilities, and the nature of the work tasks. Finally, we discuss the practical implications of our findings on the future work arrangements.

With the increasing availability of software usage and the influence of the Lean Startup mindset, more and more companies choose to innovate through internal software startups. Such startups aim at developing new business models while at the same time relying on the resources from the companies where they emerged. The evidence from both researchers and practitioners indicates that driving internal software startups is challenging. This paper seeks to address this problem by asking the research question: how to make internal software startups work? We examined a unique case of a venture builder, a company primarily focusing on building internal software startups and launching them as independent companies. Applying a Grounded Theory approach, we analyzed data on four internal software startups at the case company. The results suggest that four strategies drive the examined startups, cultural, financial, personnel, and venture arrangement. We interpret our results by drawing on earlier literature on intrapreneurship and internal ventures and suggest four recommendations to succeed with internal software startups 1 establish shared arenas for the employees, 2 provide necessary resources for experimentation in the initial phase and increase them incrementally, 3 build up in-house product management competence through coaching, and 4 harness employees own motivation to develop their own ideas., Comment: International Conference on Software Business

Psychological safety has been postulated as a key factor for the success of agile software development teams, yet there is a lack of empirical studies investigating the role of psychological safety in this context. The present study examines how work design characteristics of software development teams (autonomy, task interdependence, and role clarity) influence psychological safety and, further, how psychological safety impacts team performance, either directly or indirectly through team reflexivity. We test our model using survey data from 236 team members in 43 software development teams in Norway. Our results show that autonomy boosts psychological safety in software teams, and that psychological safety again has a positive effect on team reflexivity and a direct effect on team performance.

Software product innovation in large organizations is fundamentally chal-lenging because of restrained freedom and flexibility to conduct experi-ments. As a response, large agile companies form internal startups to initiate employ-driven innovation, inspired by Lean startup. This case study investi-gates how communities of practice support five internal startups in develop-ing new software products within a large organization. We observed six communities of practice meetings, two workshops and conducted ten semi-structured interviews over the course of a year. Our findings show that a community of practice, called the Innovation guild, allowed internal startups to help each other by collectively solving problems, creating shared practic-es, and sharing knowledge. This study confirms that benefits documented in earlier research into CoPs also hold true in the context of software product innovation in large organizations. Henceforth, we suggest that similar innova-tion guilds, as described in this paper, can support large companies in the in-novation race for new software products., Comment: Accepted to post-proceedings of XP 2021: International Conference on Agile Software Development - Workshops

To keep up with the pace of innovation, established companies are increasingly relying on internal software startups. However, succeeding with such startups is a challenging task because internal startups need to find a balance between the interests of the company and the interest of the innovator. One approach that is argued to strengthen innovation in existing companies is employee-driven innovation (EDI). This study explores this argument by examining two internal software startups in companies aligned with the principles of EDI and with a strong focus on innovation. The preliminary findings indicate that startups with EDI are characterized by commitment towards innovation, cooperative orientation, and autonomy. The findings suggest that internal software startups may be strengthened when the parent companies practice EDI., Comment: 9 pages, submitted to post-proceedings of XP 2021: International Conference on Agile Software Development - Workshops

Large global companies need to speed up their innovation activities to increase competitive advantage. However, such companies' organizational structures impede their ability to capture trends they are well aware of due to bureaucracy, slow decision-making, distributed departments, and distributed processes. One way to strengthen the innovation capability is through fostering internal startups. We report findings from an embedded multiple-case study of five internal startups in a globally distributed company to identify barriers for software product innovation: late involvement of software developers, executive sponsor is missing or not clarified, yearly budgeting and planning, unclear decision-making authority, lack of digital infrastructure for experimentation and access to data from external actors. Drawing on the framework of continuous software engineering proposed by Fitzgerald and Stol, we discuss the role of BizDev in software product innovation. We suggest that lack of continuity, rather than the lack of speed, is an ultimate challenge for internal startups in large global companies., Comment: Accepted to 16th ACM/IEEE International Conference on Global Software Engineering (ICGSE), 10 pages

It is increasingly common to introduce agile coaches to help gain speed and advantage in agile companies. Following the success of Spotify, the role of the agile coach has branched out in terms of tasks and responsibilities, but little research has been conducted to examine how this role is practiced. This paper examines the role of the agile coach through 19 semistructured interviews with agile coaches from ten different companies. We describe the role in terms of the tasks the coach has in agile projects, valuable traits, skills, tools, and the enablers of agile coaching. Our findings indicate that agile coaches perform at the team and organizational levels. They affect effort, strategies, knowledge, and skills of the agile teams. The most essential traits of an agile coach are being emphatic, people-oriented, able to listen, diplomatic, and persistent. We suggest empirically based advice for agile coaching, for example companies giving their agile coaches the authority to implement the required organizational changes within and outside the teams., Comment: 10 pages