Developer Experience (DevEx) refers to the overall experience of software developers when interacting with tools, processes, and organizational environments. This paper reports on a DevEx survey conducted within the ICT division of the Swedish Transport Administration (STA), one of the largest software development organizations in the Swedish public sector. The survey, completed by 98 out of 122 invited software engineers, included both quantitative and qualitative data. The initial results show strong (positive) scores in cultural factors, skills and competence, perceived responsibility and accountability, indicating a collaborative and supportive work environment. In contrast, the most frequently reported hindrances were meetings, context switching and inefficient work practices. Along with the analysis our study presents practitioner-oriented recommendations and lessons learned when conducting similar DevEx initiatives. 

In the postpandemic era, attitudes toward remote work appeared to undergo a lasting transformation, with a high degree of location flexibility becoming increasingly common. Yet, in recent years, many organizations have introduced return-to-office (RTO) initiatives aimed at re-establishing traditional workplace dynamics and prioritizing in-person collaboration. These mandates have drawn significant attention and criticism for limiting software developers flexibility, diminishing well-being, and potentially impacting women disproportionally. This study seeks to understand software developers preferences and actual work behaviors in companies that promote in-office presence. Specifically, we investigate whether certain demographic groups, including women, are differentially affected by RTO initiatives. We also explore a range of factors that may influence individual preferences for remote or on-site work, beyond gender-based assumptions. We report findings from a survey conducted in two large Scandinavian companies engaged in the development of software-intensive systems and services. Data analysis includes descriptive statistics, contingency tables along with post hoc tests, chi-square test of association, and Cramér's (Formula presented.) for effect sizes. Our findings reveal that gender differences among software developers in both industrial cases are minimal and statistically insignificant. Instead, other variables—such as the degree of collaborative work, commute time, and responsibility to support teammates—demonstrate a stronger association with both actual and preferred office attendance. Our results challenge common narratives around gendered responses to RTO mandates, suggesting that other contextual and task-related factors may play a more decisive role. While the impact of RTO initiatives should not be dismissed, our findings indicate that a deeper understanding of work dynamics—particularly around collaboration intensity and commuting burden—is essential to designing equitable and effective work policies. Finally, our findings imply that organizational recommendations for work location must go hand in hand with task design. 

The growing complexity, the ever-ending demands for new features, and the need to become faster to remain competitive force software development organizations to rethink their development and value delivery practices. While continuous delivery has become more popular, it still relies mainly on internal metrics, ad-hoc data, and expert opinions. As a result, software organizations stumble to find the balance between improving internal system quality and delivering external value. In fact, understanding and measuring customer value is on itself essential. In this PhD project, we aim for a better understanding of customer value and develop measurement instruments to be integrated with internal perspectives to drive proactive and continuous internal improvement while delivering relevant customer value. 

Work in software development companies has become increasingly hybrid with employees altering days of working in the office with days of working remotely from home. Yet, little is know about the efficiency of such way of working because the current scale of remote working is unprecedented. In this paper, we present our findings from a company-wide survey at Storebrand - a large-scale Norwegian fintech company, focusing on perceived performance. Our analysis of 192 responses shows that most employees report being able to perform the planned tasks. Further, half of respondents perceive to have increased work hours. Through qualitative analysis of open-ended commentaries of respondents we learned that remote working has dual effects on the perceived work hours - some employees report working longer hours and others report having more work time due to efficient use of the time throughout the day. Finally, we recommend managers to discuss and address the concerning habits of employees caused by increased connectivity and inability to stop working, before these lead to burnout and disturbances in the work/life balance. 

Background: Software companies must balance fast delivery and quality, a trade-off that often introduces technical debt and wastes developer's time. Technical debt tends to increase as software evolves, which is assumed to slow down development and maintenance activities. However, the potential relationship between technical debt and lead time lacks empirical evidence.

Objective: This paper reports an empirical study to explore the potential relationship between technical debt and lead time in resolving Jira tickets. We further aim to measure the extent to which technical debt can explain the variation in lead time.

Method: We conducted an industrial case study to explore this relationship in six components, each of which was analyzed individually. Technical debt was measured using SonarQube and normalized with the component's size. Lead times to resolve Jira tickets were collected from Jira and averaged monthly.

Results: The study found little to no correlation between technical debt and lead time to resolve Jira tickets in five components, with technical debt explaining a variation in lead time ranging from 0% to 41%. However, it is less than 30% in most of the components.

Conclusion: Technical debt alone does not fully explain the variation in lead time. There should be some other confounding variables (e.g., size and complexity of the changes, number of teams involved, priorities, component ownership) affecting lead time or a residual effect, i.e., interest, that might manifest later. Further investigation into those confounding variables is essential. 

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. 

Background: Modern workplaces have irreversibly changed their attitudes toward remote working, allowing different degrees of remotely working. Decisions about the influence of restricted remote working and mandatory office presence often raise the question of disproportional impact on different genders.

Aim: Our aim is to achieve a better understanding of whether WFH has a gender-segregated motivation and what other factors predict individual choices to work onsite or remotely.

Method: We report results from a company-wide survey conducted in NorBank, a Norwegian fintech company. The data is analyzed using descriptive statistics, contingency tables, Chi-Square test of association along with post hoc tests. We illustrated the results by using diverged chart bars.

Results: The results show that gender differences among software engineers are negligible and insignificant. Further, software engineers work more remotely than employees in other departments. We also found that engineers without managerial responsibilities are less at the office, and those who live further to their job, tend to work more remotely. With respect to preferences to work remotely, we found that younger engineers choose to work at the office more often than the senior engineers.

Conclusions: We found that the strongest predictor of the degree of remote working is not the gender but commute time and role. This also means that any analysis of general populations (as the analysis of all employees at NorBank) shall be approached with care because it may lead to flawed conclusions due to the different distributions of gender and roles in different departments. 

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. 

We examine how remote work is institutionalized in eight companies, and solicit employees' needs at the workplace. Based on these insights, we summarize actionable advice for policy makers, facility managers and employees to promote on-site work, which is likely to help many companies to rejuvenate life in their offices.

Software is becoming essential for most products, manufacturing processes, and back-office functions. The speed of delivering new features and refining the product is critical to remaining competitive. Software organizations may adopt continuous engineering practices to become more efficient. However, retrofitting an organization with a pipeline is challenging. Importantly, the most significant challenges and opportunities, are related to, but stem from outside the engineering realm and require rethinking customer relationships and business models. This paper presents a hierarchy of continuous engineering benefits and challenges. It is aimed to guide the adoption of continuous practices in an organization to determine the current and target level of adoption, given organizational context, ambitions, and domain constraints. IEEE