Context: Prior work has studied how personality or social identity separately relate to software team productivity, but no study has compared them as predictors within the same model. Objective: We investigate which factors from personality (Big Five) and social identity (Collective Self-Esteem) best predict perceived team productivity in software development, and whether both constructs contribute. Method: We surveyed 71 software professionals, measuring Big Five personality traits (Mini-IPIP), Collective Self-Esteem (Luhtanen and Crocker scale), and self-assessed team productivity. We used multiple linear regression with backward elimination. Results: Predictors from both constructs survived backward elimination. Agreeableness was the strongest predictor of perceived team productivity, followed by Public Collective Self-Esteem and Membership Esteem, with Neuroticism predicting productivity negatively. Intellect/Openness sat near the inclusion threshold and should be read as tentative given the lenient alpha. The retained model explains roughly a third of the variance in perceived team productivity. Conclusion: Personality and social identity are complementary predictors of software team productivity. The three strongest predictors come from both constructs, suggesting practitioners should attend to both individual traits and group identification when composing and managing teams.

Abstract Large Language Models (LLMs) have the potential to automate knowledge-intensive interactions in enterprise systems, yet their adoption is often limited. One reason is a lack of user trust. This study examines how trust can be systematically engineered into an LLM-driven, multi-agent chatbot that handles routine human-resources (HR) queries. We follow a two-cycle Design Science Research methodology. Cycle 1 triangulated a systematic literature review with a thematic analysis over semi-structured interviews of six employees at a global firm and a confirmatory workshop with five AI experts to elicit and validate trust requirements . Cycle II instantiated these requirements in a multi-agent LLM chatbot prototype artifact and evaluated whether the artifact satisfies them through controlled user sessions and expert walkthroughs, emphasizing perceived usefulness and trust captured in post-task interviews ( $$n = 11$$ ) and operationalizing trust via alignment-oriented measures (faithfulness, answer relevancy, and adversarial robustness). The study yields a refined taxonomy of external (transparency, organizational safeguards, third-party security) and internal (model provenance, bias risk, reliability) trust factors, identifying reliability as the primary determinant of adoption. The implemented design achieved $$\ge 0.86$$ on trust-aligned metrics and was endorsed by 9/11 participants as ready for field deployment. These findings demonstrate that trust can be proactively addressed through design and offer prescriptive guidelines for software engineers seeking to embed LLMs safely and responsibly in socio-technical contexts.

This experience report introduces the Cross-Functional AI Task Force (X-FAIT) framework to bridge the gap between strategic AI ambitions and operational execution within software-intensive organizations. Drawing from an Action Research case study at a global Swedish enterprise, we identify and address critical barriers such as departmental fragmentation, regulatory constraints, and organizational inertia that can impede successful AI transformation. X-FAIT employs force field analysis, executive sponsorship, cross-functional integration, and systematic risk assessment strategies to coordinate efforts across organizational boundaries, facilitating knowledge sharing and ensuring AI initiatives align with objectives. The framework provides both theoretical insights into AI-driven organizational transformation and practical guidance for software organizations aiming to effectively integrate AI into their daily workflows and, longer-term, products.

From 2019 to 2022, Volvo Cars successfully translated our research discoveries regarding group dynamics within agile teams into widespread industrial practice. We wish to illuminate the insights gained through the process of garnering support, providing training, executing implementation, and sustaining a tool embraced by approximately 700 teams and 9,000 employees. This tool was designed to empower agile teams and propel their internal development. Our experiences underscore the necessity of comprehensive team training, the cultivation of a cadre of trainers across the organization, and the creation of a novel software solution. In essence, we deduce that an automated concise survey tool, coupled with a repository of actionable strategies, holds remarkable potential in fostering the maturation of agile teams, but we also share many of the challenges we encountered during the implementation.

About seven years ago, Volvo Cars initiated a large-scale agile transformation. Midst this journey, a significant restructuring of the R&D department took place. Our study aims to illuminate how team maturity levels are impacted during such comprehensive reorganizations. We collected data from 63 teams to comprehend the effects of organizational changes on these agile teams. Additionally, qualitative data was gathered to validate our findings and explore underlying reasons. Contrary to what was expected, the reorganization did not significantly alter the distribution of team maturity. High turnover rates and frequent reorganizations were identified as key factors to why the less mature teams remained in the early stages of team development. Conversely, teams in the second category remained stable at a higher maturity stage, primarily because the teams themselves remained largely intact, with only management structures changing. In conclusion, while reorganizations may hinder some teams' development, others maintain stability at a higher level of maturity despite substantial managerial changes.

Abstract Researchers are increasingly recognizing the importance of human aspects in software development. Because qualitative methods are used to explore human behavior in‐depth, we believe that studies using such methods will become more common. Existing qualitative software engineering guidelines do not cover the full breadth of qualitative methods and the knowledge on how to use them like in social sciences. The purpose of this study was to extend the software engineering community's current body of knowledge regarding available qualitative methods and their quality assurance frameworks and to provide recommendations and guidelines for their use. With the support of an epistemological argument and a survey of the literature, we suggest that future research would benefit from (1) utilizing a broader set of research methods, (2) more strongly emphasizing reflexivity, and (3) employing qualitative guidelines and quality criteria. We present an overview of three qualitative methods commonly used in social sciences but rarely seen in software engineering research, namely interpretative phenomenological analysis, narrative analysis, and discourse analysis. Furthermore, we discuss the meaning of reflexivity in relation to the software engineering context and suggest means of fostering it. Our paper will help software engineering researchers better select and then guide the application of a broader set of qualitative research methods.

Effective leadership is one of the key drivers of business and project success, and one of the most active areas of management research. But how does leadership work in agile software development, which emphasizes self-management and self-organization and marginalizes traditional leadership roles? To find out, this study examines agile leadership from the perspective of thirteen professionals who identify as agile leaders, in different roles, at ten different software development companies of varying sizes. Data from semi-structured interviews reveals that leadership: (1) is dynamically shared among team members; (2) engenders a sense of belonging to the team; and (3) involves balancing competing organizational cultures (e.g. balancing the new agile culture with the old milestone-driven culture). In other words, agile leadership is a property of a team, not a role, and effectiveness depends on agile team members' identifying with the team, accepting responsibility, and being sensitive to cultural conflict.

A key goal of empirical research in software engineering is to assess practical significance, which answers the question whether the observed effects of some compared treatments show a relevant difference in practice in realistic scenarios. Even though plenty of standard techniques exist to assess statistical significance, connecting it to practical significance is not straightforward or routinely done; indeed, only a few empirical studies in software engineering assess practical significance in a principled and systematic way. In this paper, we argue that Bayesian data analysis provides suitable tools to assess practical significance rigorously. We demonstrate our claims in a case study comparing different test techniques. The case study's data was previously analyzed (Afzalet al., 2015) using standard techniques focusing on statistical significance. Here, we build a multilevel model of the same data, which we fit and validate using Bayesian techniques. Our method is to apply cumulative prospect theory on top of the statistical model to quantitatively connect our statistical analysis output to a practically meaningful context. This is then the basis both for assessing and arguing for practical significance. Our study demonstrates that Bayesian analysis provides a technically rigorous yet practical framework for empirical software engineering. A substantial side effect is that any uncertainty in the underlying data will be propagated through the statistical model, and its effects on practical significance are made clear. Thus, in combination with cumulative prospect theory, Bayesian analysis supports seamlessly assessing practical significance in an empirical software engineering context, thus potentially clarifying and extending the relevance of research for practitioners.

Abstract Expert judgement is a common method for software effort estimations in practice today. Estimators are often shown extra obsolete requirements together with the real ones to be implemented. Only one previous study has been conducted on if such practices bias the estimations. We conducted six experiments with both students and practitioners to study, and quantify, the effects of obsolete requirements on software estimation. By conducting a family of six experiments using both students and practitioners as research subjects ( $$N=461$$ N = 461 ), and by using a Bayesian Data Analysis approach, we investigated different aspects of this effect. We also argue for, and show an example of, how we by using a Bayesian approach can be more confident in our results and enable further studies with small sample sizes. We found that the presence of obsolete requirements triggered an overestimation in effort across all experiments. The effect, however, was smaller in a field setting compared to using students as subjects. Still, the over-estimations triggered by the obsolete requirements were systematically around twice the percentage of the included obsolete ones, but with a large 95% credible interval. The results have implications for both research and practice in that the found systematic error should be accounted for in both studies on software estimation and, maybe more importantly, in estimation practices to avoid over-estimations due to this systematic error. We partly explain this error to be stemming from the cognitive bias of anchoring-and-adjustment, i.e. the obsolete requirements anchored a much larger software. However, further studies are needed in order to accurately predict this effect.

There is some ambiguity of what agile means in both research and practice. Authors have suggested a diversity of different definitions, through which it is difficult to interpret what agile really is. The concept, however, exists in its implementation through agile practices. In this vision paper, we argue that adopting an agile approach boils down to being more responsive to change. To support this claim, we relate agile principles, practices, the agile manifesto, and our own experiences to this core definition. We envision that agile transformations would be, and are, much easier using this definition and contextualizing its implications.

When large industrial organizations change to (or start with) an agile approach to operations, managers and some employees are supposed to be “agile leaders” often without being given a clear definition of what that comprises when building agile teams. An inductive thematic analysis was used to investigate what 15 appointed leaders actually do and perceive as challenges regarding group dynamics working with an agile approach. Team maturity , Team design , and Culture and mindset were all categories of challenges related to group dynamics that the practitioners face and manage in their work-life that are not explicitly mentioned in the more process-focused agile transformation frameworks. The results suggest that leader mitigation of these three aspects of group dynamics is essential to the success of an agile transformation.

Abstract With the agile approach to managing software development projects comes an increased dependability on well‐functioning teams, since many of the practices are built on teamwork. The objective of this study was to investigate if, and how, team development from a group psychological perspective is related to some work practices of agile teams. Data were collected from 34 agile teams (200 individuals) from six software development organizations and one university in both Brazil and Sweden using the Group Development Questionnaire (Scale IV) and the Perceptive Agile Measurement (PAM). The result indicates a strong correlation between levels of group maturity and the two agile practices iterative development and retrospectives. We, therefore, conclude that agile teams at different group development stages adopt parts of team agility differently, thus confirming previous studies but with more data and by investigating concrete and applied agile practices. We thereby add evidence to the hypothesis that an agile implementation and management of agile projects need to be adapted to the group maturity levels of the agile teams.

Background. There are some publications in software engineering research that aim at guiding researchers in assessing validity threats to their studies. Still, many researchers fail to address many aspects of validity that are essential to quantitative research on human factors.

Abstract Empirical evidence regarding the connection between group development (maturity) and the success of software development teams is lacking. The purpose of this research is to gain a qualitative and quantitative understanding of how velocity and planning effectiveness of software teams connect to a group development model. The Group Development Questionnaire was given to 19 software developers from 4 work groups to assess their group development maturity. The work groups' responses to the survey were checked for correlation with development velocity and planning effectiveness. Semistructured interviews were conducted with 16 individuals from the same 4 work groups to explore issues about their group maturity and to validate the responses of the interviewees in the Group Development Questionnaire. The measurement of the fourth stage of group development had a strong association with the planning effectiveness measurement, which means that a team with less issues in the fourth phase of group development is more effective in adhering to its plans. On the other hand, group development and velocity showed no significant convergent validity. We conclude that the dynamics within software development teams might correlate to their ability to deliver the expected outcome as planned but not to their ability to develop tasks faster.

Agile processes explicitly focus more on team-work than more traditional management techniques when building software. With high velocity and responsiveness on team-level come the risk of interpersonal conflict in the agile organizations. Through a survey with 68 software developers from three large Swedish companies, I found that the presence of interpersonal conflict was negatively connected to the agile practices Iterative Development and Customer Access. The agile practices Iteration Planning and Iterative Development were positively linked to the measurement of the developers' perceived team productivity. However, Continuous Integration & Testing was negatively connected to productivity. These results show which agile practices are directly linked to team productivity, but also, and more importantly, indicate which of the agile practices that might be more prone to not work as intended, when the team struggles with interpersonal conflict. Therefore, I argue that members of agile teams need training in conflict resolution techniques in order to lower the risk of interpersonal conflict negatively affecting team productivity.

Unit testing has been considered as having a key role in building high quality software, and therefore it has been widely used in practice. However, data on the relationship between unit testing and aspects of software quality remain scarce. A survey study with 235 survey responses from seven organizations was conducted in order to understand the correlation between practitioners' perception of code quality and unit testing practices. In addition, we conducted a case study in one of these organizations to investigate the correlation between unit test coverage and post-unit test defects. In both cases none or weak correlations were found. We recommend further research on the effectiveness of different testing practices in order to help practitioners to understand how to best allocate their resources to the testing chain.

Many tools have been created for measuring the agility of software teams, thus creating a saturation in the field. Three agile measurement tools were selected in order to validate whether they yield similar results. The surveys of the tools were given to teams in Company A ( $$N=30$$ ). The questions were grouped into agile practices which were checked for correlation in order to establish convergent validity. In addition, we checked whether the questions identified to be the same among the tools would be given the same replies by the respondents. We could not establish convergent validity since the correlations of the data gathered were very few and low. In addition, the questions which were identified to have the same meaning among the tools did not have the same answers from the respondents. We conclude that the area of measuring agility is still immature and more work needs to be done. Not all tools are applicable to every team but they should be selected on the basis of how a team has transitioned to agile.