arXiv subjects

Lucas Gren

Publications and source records attributed to Lucas Gren.

47 records · Page 3Linked to original sources

arXiv2019

The prospects of a quantitative measurement of agility: A validation study on an agile maturity model

Agile development has now become a well-known approach to collaboration in professional work life. Both researchers and practitioners want validated tools to measure agility. This study sets out to validate an agile maturity measurement model with statistical tests and empirical data. First, a pretest was conducted as a case study including a survey and focus group. Second, the main study was conducted with 45 employees from two SAP customers in the US. We used internal consistency (by a Cronbach's alpha) as the main measure for reliability and analyzed construct validity by exploratory principal factor analysis (PFA). The results suggest a new categorization of a subset of items existing in the tool and provides empirical support for these new groups of factors. However, we argue that more work is needed to reach the point where a maturity models with quantitative data can be said to validly measure agility, and even then, such a measurement still needs to include some deeper analysis with cultural and contextual items.

cs.SE↗

arXiv2019

Group development and group maturity when building agile teams: A qualitative and quantitative investigation at eight large companies

The agile approach to projects focuses more on close-knit teams than traditional waterfall projects, which means that aspects of group maturity become even more important. This psychological aspect is not much researched in connection to the building of an "agile team." The purpose of this study is to investigate how building agile teams is connected to a group development model taken from social psychology. We conducted ten semi-structured interviews with coaches, Scrum Masters, and managers responsible for the agile process from seven different companies, and collected survey data from 66 group-members from four companies (a total of eight different companies). The survey included an agile measurement tool and the one part of the Group Development Questionnaire. The results show that the practitioners define group developmental aspects as key factors to a successful agile transition. Also, the quantitative measurement of agility was significantly correlated to the group maturity measurement. We conclude that adding these psychological aspects to the description of the "agile team" could increase the understanding of agility and partly help define an "agile team." We propose that future work should develop specific guidelines for how software development teams at different maturity levels might adopt agile principles and practices differently.

cs.SE↗

arXiv2019

Work Motivational Challenges Regarding the Interface Between Agile Teams and a Non-Agile Surrounding Organization: A case study

There are studies showing what happens if agile teams are introduced into a non-agile organization, e.g. higher overhead costs and the necessity of an understanding of agile methods even outside the teams. This case study shows an example of work motivational aspects that might surface when an agile team exists in the middle of a more traditional structure. This case study was conducted at a car manufacturer in Sweden, consisting of an unstructured interview with the Scrum Master and a semi-structured focus group. The results show that the teams felt that the feedback from the surrounding organization was unsynchronized resulting in them not feeling appreciated when delivering their work. Moreover, they felt frustrated when working on non-agile teams after have been working on agile ones. This study concludes that there were work motivational affects of fitting an agile team into a non-agile surrounding organization, and therefore this might also be true for other organizations.

cs.SE↗

arXiv2019

Is it Possible to Disregard Obsolete Requirements? - An Initial Experiment on a Potentially New Bias in Software Effort Estimation

Effort estimation is a complex area in decision-making, and is influenced by a diversity of factors that could increase the estimation error. The effects on effort estimation accuracy of having obsolete requirements in specifications have not yet been studied. This study aims at filling that gap. A total of 150 students were asked to provide effort estimates for different amounts of requirements, and one group was explicitly told to disregard some of the given requirements. The results show that even the extra text instructing participants to exclude requirements in the estimation task, had the subjects give higher estimates. The effect of having obsolete requirements in requirements specifications and backlogs in software effort estimation is not taken into account enough today, and this study provides empirical evidence that it possibly should. We also suggest different psychological explanations to the found effect.

cs.SE↗

arXiv2019

A fourth explanation to Brooks' Law - The aspect of group developmental psychology

Brooks' Law is often referred to in practice and states that adding manpower to a late software project makes it even later. Brooks' himself gave three explanation only related to concrete task-related issues, like introducing new members to the work being done, communication overheads, or difficulty dividing some programming tasks. Through a description of group developmental psychology we argue for a fourth explanation to the law by suggesting that the group will fall back in its group development when new members are added, resulting in rework setting group norms, group goals, defining roles etc. that will also change over time. We show that this fourth explanation is important when trying to understanding Brooks' Law, and that adding the group developmental perspective might help software development organizations in managing projects.

cs.SE↗

arXiv2019

Group Maturity and Agility, Are They Connected? - A Survey Study

The focus on psychology has increased within software engineering due to the project management innovation "agile development processes". The agile methods do not explicitly consider group development aspects; they simply assume what is described in group psychology as mature groups. This study was conducted with 45 employees and their twelve managers (N=57) from two SAP customers in the US that were working with agile methods, and the data were collected via an online survey. The selected Agility measurement was correlated to a Group Development measurement and showed significant convergent validity, i.e., a more mature team is also a more agile team. This means that the agile methods probably would benefit from taking group development into account when its practices are being introduced.

cs.SE↗

arXiv2019

Useful Statistical Methods for Human Factors Research in Software Engineering: A Discussion on Validation with Quantitative Data

In this paper we describe the usefulness of statistical validation techniques for human factors survey research. We need to investigate a diversity of validity aspects when creating metrics in human factors research, and we argue that the statistical tests used in other fields to get support for reliability and construct validity in surveys, should also be applied to human factors research in software engineering more often. We also show briefly how such methods can be applied (Test-Retest, Cronbach's α, and Exploratory Factor Analysis).

cs.SE↗

arXiv2019

What software engineering can learn from research on affect in social psychology

Social psychology researchers have, traditionally, focused on the construct of thinking rather than on feeling. Since the beginning of the 21st century, social science researchers have, however, increasingly explored the effects of affect. Their work has repeatedly recognized that affects play a crucial role in determining people's behavior. In this short paper, we argue that software engineering studies on affect would benefit from using more of the knowledge that social science researchers have acquired. Without accounting for their findings, we risk re-inventing the wheel. Also, without a profound understanding of the complex interplay between social context and affect, we risk creating overly simplistic solutions that might have considerable long-term adverse effects for software engineers.

cs.SE↗

arXiv2019

Social Identity in Software Development

An agile approach has become very popular over the last decade, which requires good communication and teamwork within teams as well as with outside stakeholders. Therefore, social interaction is central for a software development team to be successful. Such social interactions form social identities and social structures in both teams and organizations. This study investigates possible effects that the social identity of individuals may have on the effectiveness of software development through seven in-dept interviews. The qualitative data from interviews were analyzed and summarized using summative content analysis, and the seven individuals also answered a questionnaire on social identity taken from social psychology research. The qualitative result shows that aspects of social identity affect software developers' behavior, and that we need to build cross-functional stable teams over time also from a pure social identity perspective in addition to the product related aspects to avoid a decreased effectiveness. However, we did not see clear connections to our operationalization of effectiveness in this study, and the quantitative analysis was also inconclusive, but we see value in our suggested method when investigating social identity in software development.

cs.SE↗

arXiv2018

Non-Technical Individual Skills are Weakly Connected to the Maturity of Agile Practices

Context: Existing knowledge in agile software development suggests that individual competency (e.g. skills) is a critical success factor for agile projects. While assuming that technical skills are important for every kind of software development project, many researchers suggest that non-technical individual skills are especially important in agile software development. Objective: In this paper, we investigate whether non-technical individual skills can predict the use of agile practices. Method: Through creating a set of multiple linear regression models using a total of 113 participants from agile teams in six software development organizations from The Netherlands and Brazil, we analyzed the predictive power of non-technical individual skills in relation to agile practices. Results: The results show that there is surprisingly low power in using non-technical individual skills to predict (i.e. explain variance in) the mature use of agile practices in software development. Conclusions: Therefore, we conclude that looking at non-technical individual skills is not the optimal level of analysis when trying to understand, and explain, the mature use of agile practices in the software development context. We argue that it is more important to focus on the non-technical skills as a team-level capacity instead of assuring that all individuals possess such skills when understanding the use of the agile practices.

cs.SE↗

arXiv2018

Standards of Validity and the Validity of Standards in Behavioral Software Engineering Research: The Perspective of Psychological Test Theory

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. Goal. This paper has the goal of triggering a change of mindset in what types of studies are the most valuable to the behavioral software engineering field, and also provide more details of what construct validity is. Method. The approach is based on psychological test theory and draws upon methods used in psychology in relation to construct validity. Results. In this paper, I suggest a different approach to validity threats than what is commonplace in behavioral software engineering research. Conclusions. While this paper focuses on behavioral software engineering, I believe other types of software engineering research might also benefit from an increased focus on construct validity.

cs.SE↗