Experiences from Measuring Learning and Performance in Large-Scale Distributed Software Development

Abstract

Background: Research on teams originated from the social sciences and brought a number of new topics into the repertoire of software engineering. Teams and teamwork are recognized for the promised benefits of i.e. increased performance. Performance is often linked to experience gains, and along with individual learning teamwork facilitates what is recognized as group learning. Aims: In this paper, we report our lessons learned from an attempt to study the relationship between group learning and performance in a large-scale software project. Method:We conducted an exploratory case study of an on-going large-scale distributed project in Ericsson. The data collected included archival data and both unstructured and semi-structured interviews. The data was analyzed using descriptive statistics, charts and regression analysis. Results:The results suggest that some teams improved their performance over time until they were forced to work cooperate with several other teams. However, it is not completely clear role of accumulated experience and other aspects, such as team stability and number of developers. Conclusions: We believe that ad-hoc team formation and team member rotation might have resulted in a failure to benefit from group learning. In addition, the fact that developers worked simultaneously on different tasks could have hindered their performance. However, we believe that further research must be conducted to provide a stronger evidence about the identified result. Based on the experience acquired by conducting this study, we report some lessons learned that can support researchers and practitioners when investigating the topic addressed in this paper.

Towards a theory of software development expertise

“…We asked those participants to describe how the decline manifested itself and to suggest possible reasons. The main categories we assigned to those answers were: 1. different reasons for demotivation (34), 2. changes in the work environment (32), 3. age-related decline (13), 4. changes in attitude (10), and 5. shifting towards other tasks (7). The most common reason for an increased demotivation was non-challenging work (8), often caused by tasks becoming routine over time.…”

“…Regarding employed metrics, participants reported using simple metrics such as the commit freqency, lines of code added / deleted, or number of issues resolved. Further, they reported to use static analysis (18) tools such as SonarQube, FindBugs, and Checkstyle, or to use GitHub's activity overview (10). In this point, there was a difference between the answers in S2 and S3: GitHub's activity overview was mentioned almost exclusively by the active Java developers (9).…”

“…What is important are a mentor's character (29), skills (19), his/her experience (16), and his/her role as a source for feedback (20) and as a motivator (19). The most common characteristics of mentors were being guiding (10), patient (8), and open-minded (7). The most important aspect of a mentor's feedback were comments about code qality (7).…”

“…To assess task-specific Java knowledge, one could rely on commercially available tests like the exams for Oracle's Java certification. Britto et al [10] report on their experience measuring learning results and the associated effect on performance in a large-scale software project. Their results can help measuring the concepts education and performance.…”

Technical Debt in Large-Scale Distributed Projects: An Industrial Case Study

“…In this paper, the following variables were used for analysis: Technical Debt (TD), Task Complexity (TC), Lead Time (LT), Global Distance (GD), Total Developers (DV), Task Scaling (TS), and Team Maturity (TM). We selected these variables due to their relevance in GSE contexts and also due to the possibility to measure them in the investigated case [27], [28]. Table I presents a description of the investigated variables.…”