Context: Pair programming (PP) is more relevant than ever. As modern systems grow in complexity, knowledge sharing and collaboration across teams have become essential. However, despite well-documented benefits of PP, its adoption remains inconsistent across software teams. Objective: This study aims to understand the factors that facilitate or hinder team members’ adoption as well as lasting engagement in PP. Method: We have conducted an exploratory single-case study in a mature agile company in Norway. We collected data through two rounds of interviews with team members in different roles and performed a thematic analysis of the interviews. Results: Our key finding is that multiple factors, related to the perceptions of how PP contributes to daily work, social dynamics and learning, efforts associated with engaging in PP sessions, company and team attitudes, resources, infrastructure, and task characteristics, affect PP engagement. Conclusion: Long-term engagement in PP requires expected benefits with the practice being confirmed in firsthand experiences. Adapting the practice to each unique team, with insights drawn from collective learning, is also beneficial. Our findings will be beneficial for software practitioners seeking to make PP an integrated part of their team’s workflow.

The pandemic experiences of forced work from home (WFH) in the tech industry turned out better than expected. As a result, modern workplaces that employ software engineers have become increasingly hybrid allowing employees to alternate days spent in the office with days spent working remotely. Yet, approaches to regulate the hybrid work arrangements vary. Some companies implemented strict policies with controlled office presence while others rely on recommendations and permit greater locational flexibility. In this paper, we evaluate how different degrees of locational flexibility influence individual work arrangements and satisfaction in two comparative cases: a company with high degree of flexibility (FinCo) and a company with mandatory office presence (TelCo). Through a survey of 547 practitioners, our findings reveal that flexible policies can achieve higher voluntary office attendance than mandatory requirements. To our surprise, we found that the number of employees visiting the office at least 2-3 days per week in the company with greater flexibility was higher (68%) compared to the company with mandatory attendance (58%). The study also identifies key factors influencing work location choices, including commute time and role. The type of tasks and dependencies with colleagues also matter - employees with more WFH days tended to have more individual tasks, while those with more onsite work days engaged in more collaborative tasks and had colleagues who depended on them. Our results suggest that trust-based approaches and creating attractive office environments may be more effective than strict attendance policies in maintaining desired office presence while supporting employee satisfaction. These findings contribute practical insights for organizations seeking to establish effective post-pandemic work policies for software engineers.

Continuous Software Engineering (CSE) is widely adopted in the industry, integrating practices such as Continuous Integration and Continuous Deployment (CI/CD). Beyond technical aspects, CSE also encompasses business activities like continuous planning, budgeting, and operational processes. Coordinating these activities in large-scale product development involves multiple stakeholders, increasing complexity. This study aims to address this complexity by identifying and analyzing critical dependencies in large-scale CSE. Based on 17 semi-structured interviews conducted at two Nordic fintech companies, our preliminary findings indicate that dependencies between software teams and support functions, as well as between software teams and external entities, are the primary sources of delays and bottlenecks. As a next step, we plan to further refine our understanding of critical dependencies in large-scale CSE and explore coordination mechanisms that can better support software development teams in managing these challenges.

Abstract 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.

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 who would partake, would lose considerable development time. Observation also does not guarantee that all essential requirements are identified, and so luck plays a role. Very few experience reports exist to evaluate observational techniques in practice, and for organizations it is difficult to assess whether observation is a worthwhile activity, given its associated cost. [Results] This report presents experiences from DNV, a global leader providing maritime services who are renewing an information system to support its expert users. 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 h 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.

Abstract To have engaged and high-performing agile teams are what most organizations strive for. At the same time, there is little research on the drivers of team work engagement in the software context. Team autonomy and trust are crucial for agile teams and are suggested as potential boosters of team work engagement and performance. In this study, we apply the Job Demands-Resources model to examine the role of autonomy and trust and their impact on work engagement and team performance in agile teams. We analyze quantitative survey data from 236 team members in 43 agile teams to examine how team autonomy and trust relate to team work engagement and how engagement mediates the relationship between these factors and performance. Our results show that while both autonomy and trust are positively related to team work engagement, team trust plays a more critical role than team autonomy. Teams with high team trust showed higher engagement, which enhanced team performance. Our results highlight the importance of social factors such as trust in creating conditions for high performance in agile teams through its effect on team work engagement.

Abstract The product manager (PM) role is well established in leading technological companies, such as Google, Amazon, Microsoft, and Facebook. PMs are responsible for integrating technical, design, and business perspectives when developing software products and product portfolios. In agile methods (e.g., Scrum), similar responsibilities are linked to the Product Owner (PO) role. In contrast, in large-scale agile, one can find both Product Owners and product managers who sometimes compete. Despite the widespread adoption of the product manager role, the attention toward it in the agile academic community has been surprisingly limited. In this multiple case study, we analyzed 17 interviews with 11 product managers from four agile companies. We found that the PMs facilitated continuous product experimentation and innovation, supported the product teams, and engaged in additional activities to achieve optimal product development. Our summary of the product management activities can guide product managers working in agile companies.

BACKGROUND: The COVID-19 pandemic triggered a natural experiment of an unprecedented scale as companies closed their offices and sent employees to work from home. Many managers were concerned that their engineers would not be able to work effectively from home, or lack the motivation to do so, and that they would lose control and not even notice when things go wrong. As many companies announced their post-COVID permanent remote-work or hybrid home/office policies, the question of what can be expected from software engineers who work from home becomes more and more relevant. AIMS: To understand the nature of home telework we analyze the evidence of perceived changes in productivity comparing office work before the pandemic with the work from home during the pandemic from thirteen empirical surveys of practitioners. METHOD: We analyzed data from six corporate surveys conducted in four Scandinavian companies combined with the results of seven published surveys studying the perceived changes in productivity in industrial settings. In addition, we sought explanations for the variation in perceived productivity among the engineers from the studied companies through the qualitative analysis of open-ended questions and interviews. RESULTS: Combined results of 7686 data points suggest that though on average perceived productivity has not changed significantly, there are developers who report being more productive, and developers being less productive when working from home. Positively affected individuals in some surveys form large groups of respondents (up to 50%) and mention benefiting from a better organization of work, increased flexibility and focus. Yet, there are equally large groups of negatively affected respondents (up to 51%) who complain about the challenges related to remote teamwork and collaboration, as well as emotional issues, distractions and poor home office environment and equipment. Finally, positive trends are found in longitudinal surveys, i.e., developers' productivity in the later months of the pandemic show better results than those in the earlier months. CONCLUSIONS: We conclude that behind the average "no change" lays a large variation of experiences, which means that the work from home might not be for everyone. Yet, a longitudinal analysis of the surveys is encouraging, as it shows that the more pessimistic results might be influenced by the initial experiences of an unprecedented crisis. At the end, we put forward the lessons learned during the pandemic that can inspire the new post-pandemic work policies.