Lucas Gren

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.

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, Cronbachs alpha, and Exploratory Factor Analysis).

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

Creativity Techniques for More Creative Requirements: Theory vs. Practice

Requirements engineering was initially regarded as a front-end activity to form a basis for the coming activities of software development, which can be achieved by gathering and producing unambiguous and consistent requirements. However, in recent years, requirements engineering has been recognized as a creative process. A systematic literature review followed by an online questionnaire with practitioners were employed to identify a comprehensive overview of existing empirical evidence using creativity techniques in the requirements engineering process. The results show a limited range of applied creativity techniques with insufficient empirical evidence to adequately evaluate if the techniques create more creative requirements. The contribution of this study is threefold: First, it compares which creativity techniques have been empirically evaluated in literature. Second, it compares the identified creativity techniques. Third, it includes an examination of which creativity techniques are used in industry.

On gender, ethnicity, and culture in empirical software engineering research

This note highlights the importance of investigating diversity aspects in combination in empirical research. It draws on the psychological discourse and suggests why and how software engineering scholars can use the aspect of diversity in all their research endeavors.

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.

Non-technical individual skills are weakly connected to the maturity of agile practices

Abstract 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.

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.

Group developmental psychology and software development performance

Due to the fact that software development is a product of team effort it is important to investigate the influence of group developmental psychology on software development performance. In this case study we wanted to test how performance (i.e. velocity and planning effectiveness) are related to the groups maturity level. We gave the Group Development Questionnaire (the GDQ) to 19 software developers to assess their group maturity (i.e. their progress in their group development) and ran correlation analysis against the development velocity and planning effectiveness (i.e. earned points over planned points). The results show that group maturity is correlated to planning effectiveness but not velocity, meaning that group development is connected to the teams ability to plan well, but not their ability to implement tasks fast.