• We analyze resignation patterns across 10 years (2016–2025) using HR and exit survey data from Ericsson, a large software-intensive organization. • Our results suggest that employees onboarded during the fully remote period were significantly more likely to resign within their first three years. • Stratified analysis identifies tenure, onboarding modality, and return-to-office policy as key factors influencing early attrition rates. • We demonstrate that even structured remote onboarding struggles to replicate the benefits of in-person integration, such as informal mentoring and social bonding. • Based on our findings, we recommend structured hybrid policies, including co-presence of new hires and their team mates, to mitigate attrition risks and support integration in software engineering teams. [Summary] Context: The COVID-19 pandemic permanently altered workplace structures, normalizing remote work. While flexibility has well-known benefits, critical evidence highlights challenges with fully remote arrangements, particularly for software teams. Objective: This study investigates how employee resignation patterns evolved across different work modalities –onsite, remote, and hybrid — at Ericsson, a global developer of software-intensive systems. Method: Using HR and exit survey data from 2016-2025 for technical roles in Ericsson Sweden, we analyze how tenure, onboarding modality, and reasons for resignation relate to attrition trends before, during, and after the pandemic. Results: Our findings show a marked increase in resignations from mid-2021 to mid-2023, especially among employees with less than three years of tenure. Those onboarded during the fully remote period were significantly more likely to resign early, and this pattern persisted even after Ericsson enhanced remote onboarding practices. Conversely, retention improved after the introduction of structured hybrid work policies, and survivability curves returned to pre-pandemic levels. Conclusions: Our findings suggest that fully remote onboarding, despite structural support, may hinder the formation of organizational attachment and belonging, increasing early attrition. In contexts like software engineering, where onboarding heavily relies on in-person mentoring, frequent peer interactions, and on-the-job training, selective return-to-office practices for new hires and their teams may help restore cohesion and long-term retention. These insights can guide HR leaders and policymakers in crafting post-pandemic work practices.

Background: Despite a lot of research on the effectiveness of Pair Programming (PP), the question when it is useful or less useful remains unsettled.

Context: While successful conventional software development regularly employs separate testing staff, there are successful agile teams with as well as without separate testers. Question: How does successful agile development work without separate testers? What are advantages and disadvantages? Method: A case study, based on Grounded Theory evaluation of interviews and direct observation of three agile teams; one having separate testers, two without. All teams perform long-term development of parts of e-business web portals. Results: Teams without testers use a quality experience work mode centered around a tight field-use feedback loop, driven by a feeling of responsibility, supported by test automation, resulting in frequent deployments. Conclusion: In the given domain, hand-overs to separate testers appear to hamper the feedback loop more than they contribute to quality, so working without testers is preferred. However, Quality Experience is achievable only with modular architectures and in suitable domains.

Knowledge transfer in the context of pair programming is both a desired effect and a necessary precondition. There is no detailed understanding yet of how effective and efficient knowledge transfer in this particular context actually works. My qualitative research is concerned with the analysis of professional software developer's sessions to capture their specific knowledge transfer skill in the form of comprehensible, relevant, and practical patterns.

Context: General knowledge transfer is often considered a valuable effect or side-effect of pair programming, but even more important is its role for the success of the pair programming session itself: The partners often need to explain an idea to carry the process forward. Goal: Understand the mechanisms at work when knowledge is transferred during a pair programming session; provide practical advice for constructive behavior. Method: Qualitative data analysis of recordings of actual industrial pair programming sessions. Results: Some pairs are much more efficient in their knowledge transfer than others. These pairs manage to (1) not attempt to explain multiple things at once, (2) not lose sight of a topic, (3) clarify difficult points in stages. Conclusions: Pair programming requires skill beyond software development skill. To be able to identify knowledge needs and then push such knowledge to or pull it from the partner successfully is one aspect of such skill. We characterize a number of its elements.

Previous research in the field of Agile Distributed Software Development often focused on the a synchronicity of working hours due to different time zones, as if this was the only risk when developing software in non-co-located environments. This case study reflects a near shoring setting in which this primary impediment does not exist and investigates a broader range of risks now standing out more clearly. We observed two Polish Scrum teams working for a German company, which has been successfully applying Agile Methods for over four years. We present the actual process and practices of the external teams and contrast them to the intended way of proceeding. Main result: Agile near shoring is feasible and may produce high satisfaction amongst Product Owners, but this satisfaction might be delusive if process deviations due to misunderstandings of what Agile development means go unnoticed.

The classical definition of pair programming (PP) describes it via two obvious roles: driver (the person currently having the keyboard) and observer (the other, alternatively called navigator). Although prior research has found some assumptions regarding these roles to be false, so far no alternative PP role model took hold. Instead, most PP research tacitly assumes the classical model to be true and thus PP to be no more difficult than solo programming. We perform qualitative research (using Grounded Theory Methodology) to find a more realistic role model, and have uncovered a suprising complexity: There are more than two roles, they are assumed and unassumed gradually, multiple roles can be held by one person at the same time, and some of their facets are subtle. Mastering this complexity requires specific PP skills beyond mere programming and communication skills. By ignoring such skills, previous PP studies (in particular the controlled experiments) have investigated a rather mixed bag of situations, which explains their heterogeneous results. The emerging result is that qualitative research on the PP process will lead to constructive behavioral advice (process patterns) for pair members and to more meaningful designs for quantitative PP research.