Searcharxiv⌕ Search

arXiv subjects

Lucas Gren

Publications and source records attributed to Lucas Gren.

At least 37 records · Page 2Linked to original sources
arXiv2019

The perceived effects of group developmental psychology training on agile software development teams

Research has shown that the maturity of small workgroups from a psychological perspective is intimately connected to team agility. We, therefore, tested if agile team members appreciated group development psychology training. Our results show that the participating teams seem to have a very positive view of group development training and state that they now have a new way of thinking about teamwork and new tools to deal with team-related problems. We, therefore, see huge potential in training agile teams in group development psychology since the positive effects might span over the entire software development organization.

cs.SE↗
arXiv2019

Do internal software quality tools measure validated metrics?

Internal software quality determines the maintainability of the software product and influences the quality in use. There is a plethora of metrics which purport to measure the internal quality of software, and these metrics are offered by static software analysis tools. To date, a number of reports have assessed the validity of these metrics. No data are available, however, on whether metrics offered by the tools are somehow validated in scientific studies. The current study covers this gap by providing data on which tools and how many validated metrics are provided. The results show that a range of metrics that the tools provided do not seem to be validated in the literature and that only a small percentage of metrics are validated in the provided tools.

cs.SE↗
arXiv2019

Evolution of statistical analysis in empirical software engineering research: Current state and steps forward

Software engineering research is evolving and papers are increasingly based on empirical data from a multitude of sources, using statistical tests to determine if and to what degree empirical evidence supports their hypotheses. To investigate the practices and trends of statistical analysis in empirical software engineering (ESE), this paper presents a review of a large pool of papers from top-ranked software engineering journals. First, we manually reviewed 161 papers and in the second phase of our method, we conducted a more extensive semi-automatic classification of papers spanning the years 2001--2015 and 5,196 papers. Results from both review steps was used to: i) identify and analyze the predominant practices in ESE (e.g., using t-test or ANOVA), as well as relevant trends in usage of specific statistical methods (e.g., nonparametric tests and effect size measures) and, ii) develop a conceptual model for a statistical analysis workflow with suggestions on how to apply different statistical methods as well as guidelines to avoid pitfalls. Lastly, we confirm existing claims that current ESE practices lack a standard to report practical significance of results. We illustrate how practical significance can be discussed in terms of both the statistical analysis and in the practitioner's context.

cs.SE↗
arXiv2019

The Connection Between Burnout and Personality Types in Software Developers

This paper examines the connection between the Five Factor Model personality traits and burnout in software developers. This study aims to validate generalizations of findings in other fields. An online survey consisting of a miniaturized International Personality Item Pool questionnaire for measuring the Five Factor Model personality traits, and the Shirom-Melamed Burnout Measure for measuring burnout, were distributed to open source developer mailing lists, obtaining 47 valid responses. The results from a Bayesian Linear Regression analysis indicate a strong link between neuroticism and burnout confirming previous work, while the other Five Factor Model traits were not adding power to the model. It is important to note that we did not investigate the quality of work in connection to personality, nor did we take any other confounding factors into account like, for example, teamwork. Nonetheless, employers could be aware of, and support, software developers with high neuroticism.

cs.SE↗
arXiv2019

Choosing agile or plan-driven enterprise resource planning (ERP) implementations -- A study on 21 implementations from 20 companies

Agile methods have gotten a good reputation for managing projects in many different sectors. A challenge among practitioners in the ERP (Enterprise Resource Planning) domain, is to decide if an agile method is suitable or not for new projects. This study investigates how decision-makers select between agile and plan-driven ERP implementation projects in relation to known factors from previous research. We selected projects that the decision-makers assessed as successful, but borderline, agile and plan-driven projects already implemented and let project managers fill out a survey consisting of key agile or plan-driven characteristics. We found that the assessment made by decision-makers did not differ on any aspects except higher executive buy-in for process change, and the prioritization of low cost in the agile projects. This study highlights the difficulty in selecting implementation strategy for a large part of the ERP implementations, and the data show that the decision-makers could not make such a decision at an early point in time without contextual knowledge.

cs.SE↗
arXiv2019

Social Influence in Agile Requirements Engineering

Agile requirements engineering implies more complex communication patterns since even the developers are supposed to have direct contact with customers. With more face-to-face communication comes social-psychological factors influencing the requirements. Studies have pointed at the importance of negotiation training, but I argue that more basic human traits can be triggered in favor of the negotiator with the most knowledge of social influence research and practice. I suggest a plan of how research in social influence and requirements facilitation can be conducted, mostly through experimentation.

cs.SE↗
arXiv2019

Agile Process Consultation -- An Applied Psychology Approach to Agility

An agile change effort in an organization needs to be understood in relation to human processes. Such theory and accompanying tools already existed almost 50 years ago in applied psychology. The core ideas of Agile Process Consultation are that a client initiating a change toward more agility often does not know what is wrong and the consultant needs to diagnose the problem jointly with the client. It is also assumed that the agile consultant cannot know the organizational culture of the client's organization, which means that the client needs to be making the decisions based on the suggestions provided by the consultant. Since agile project management is spreading across the enterprise and outside of software development, we need situational approaches instead of prescribing low-level practices.

cs.SE↗
arXiv2019

The Importance of Conflict Resolution Techniques in Autonomous Agile Teams

Today, software companies usually organize their work in teams. Social science research on team development has shown that for a team to reach a productive and autonomous stage, it has to be able to manage internal conflicts and disagreements efficiently. To better facilitate the team development process, we argue that software engineers' needs additional training in negotiation skills and conflict resolution. In this position paper, we outline ideas for what aspects to consider in such training. As an example, we argue that a majority of the conflicts originate from team-level factors and that they, therefore, should be managed on the team-level instead of in relation to dyads.

cs.SE↗
arXiv2019

Studying Attitudes and Social Norms in Agile Software Development

The purpose of this paper is to review research on attitudes and social norms and connect it to the agile software development context. Furthermore, I propose additional theories from social psychology (mainly the theory of planned behavior and using the degree of internalization of social norms) that would most certainly be useful for further sense-making of human factors-related research on agile teams.

cs.SE↗
arXiv2019

Using the agile adoption framework to assess agility and guide improvements

Agility implies a set of principles that need to be followed in order to have the proposed responsiveness to change. This paper presents how the Agile Adoption Framework can be used to assess agility and pinpoint focus areas for companies that want to improve. Management found it useful in general to get data on possible focus points for improvement in their agile transformation. We believe the suggested tool could be useful as one step in the agile process assessment.

cs.SE↗
arXiv2019

The Connections Between Group Maturity, Software Development Velocity and Planning Effectiveness

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.

cs.SE↗
arXiv2019

Learning more from crossing levels: Investigating agility at three levels of the organization

Scholars have tried to explain how organizations can build agile teams by only looking at one level of analysis. We argue in this short paper that lessons can be learned from organizational science results explaining variance on three different abstraction levels of organizations. We suggest agility needs to be explained from organizational (macro), the team (meso), and individual (micro) levels to provide useful and actionable guidelines to practitioners. We are currently designing such studies and hope that they will eventually result in validated measurements that can be used to prevent companies from investing in the wrong areas when trying to move towards more agility.

cs.SE↗
arXiv2019

On the Relation Between Unit Testing and Code Quality

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.

cs.SE↗
arXiv2019

The links between agile practices, interpersonal conflict, and perceived productivity

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.

cs.SE↗
arXiv2019

The Systems Approach to Change and the Agile Software Development Context

There is a diversity of models explaining organizational culture and how these complex aspects can be addressed in connection to organizational change efforts. This workshop paper claims that models already exist for dealing with the cultural change that an agile transition is in the software engineering context. Instead of realizing this again through agile success stories, and thus reinventing the wheel, it is argued that the research in the software engineering field should build on these models instead and investigate how/if they differ. Practitioners already work as the change agents described in other fields and they should get recognition through the presence and integration of these models in the software engineering process research.

cs.SE↗
arXiv2019

Trying to Increase the Mature Use of Agile Practices by Group Development Psychology Training - An Experiment

There has been some evidence that agility is connected to the group maturity of software development teams. This study aims at conducting group development psychology training with student teams, participating in a project course at university, and compare their group effectiveness score to their agility usage over time in a longitudinal design. Seven XP student teams were measured twice (43+40), which means 83 data points divided into two groups (an experimental group and one control group). The results showed that the agility measurement was not possible to increase by giving a 1.5-hour of group psychology lecture and discussion over a two-month period. The non-significant result was probably due to the fact that 1.5 hours of training were not enough to change the work methods of these student teams, or, a causal relationship does not exist between the two concepts. A third option could be that the experiential setting of real teams, even at a university, has many more variables not taken into account in this experiment that affect the two concepts. We therefore have no conclusions to draw based on the expected effects. However, we believe these concepts have to be connected since agile software development is based on teamwork to a large extent, but there are probably many more confounding or mediating factors.

cs.SE↗
arXiv2019

Agility Measurements Mismatch: A Validation Study on Three Agile Team Assessments in Software Engineering

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 sim-ilar 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.

cs.SE↗