SEIP session

There is a steadily increasing interest in the agile practice of continuous integration. Consequently, there is great diversity in how it is interpreted and implemented, and a need to study, document and analyze how automated software integration flows are implemented in the industry today. In this paper we study five separate cases, using a descriptive model developed to address the variation points in continuous integration practice discovered in literature. Each case is discussed and evaluated individually, whereupon six guidelines for the design and implementation of automated software integration are presented. Furthermore, the descriptive model used to document the cases is evaluated and evolved.

Context: What can we learn from historic data that is collected in three software companies that on a daily basis had to cope with highly complex project portfolios? Objective: In this paper we analyze a large dataset, containing 352 finalized software engineering projects, with the goal to dis¬cover what factors affect software project performance, and what actions can be taken to increase project performance when building a software project portfolio. Method: The software projects were classified in four quadrants of a Cost/Duration matrix: analysis was performed on factors that were strongly related to two of those quadrants, Good Practices and Bad Practices. A ranking was performed on the factors based on statistical significance. Results: The paper results in an inventory of ‘what factors should be embraced when building a project portfolio?’ (Success Factors), and ‘what factors should be avoided when doing so?’ (Failure Factors). Conclusion: The major contribution of this paper is that it analyzes characteristics of best performers and worst performers in the dataset of software projects, resulting in 7 Success Factors (a.o. steady heartbeat, a fixed, experienced team, agile (Scrum), and release-based), and 9 Failure Factors (a.o. once-only project, dependencies with other systems, technology driven, and rules- and regulations driven.

Background: Distributed Pair Programming can be performed via screensharing or via a distributed IDE. The latter offers the freedom of concurrent editing (which may be helpful or damaging) and has even more awareness deficits than screen sharing.
Objective: Characterize how competent distributed pair programmers may handle this additional freedom and these additional awareness deficits and characterize the impacts on the pair programming process.
Method: A revelatory case study, based on direct observation of a single, highly competent distributed pair of industrial software developers during a 3-day collaboration. We use recordings of these sessions and conceptualize the phenomena seen.
Results: 1. Skilled pairs may bridge the awareness deficits without visible obstruction of the overall process. 2. Skilled pairs may use the additional editing freedom in a useful limited fashion, resulting in potentially better fluency of the process than local pair programming.
Conclusion: When applied skillfully in an appropriate context, distributed-pair programming can (not will!) work at least as well as local pair programming.

Since 2010, SAP has taught more than 4000 developers in agile software engineering practices. Hence, the company offers a unique setting to learn about the benefits of agile development. In this paper, we discuss how developers perceive the effects of pair programming and test automation on software quality, delivered feature scope, and team work. We draw our findings from a company-wide survey with answers from 174 developers working in 74 teams and 15 product owners from five locations world-wide. We complement these findings with insights from two in-depths development team case studies. Our findings confirm existing promises that the studied practices lead to better software quality. Deviating from existing assumptions, however, developers do not report a significant drop in their development speed. Moreover, high adopters are more proud of their own contributions to the team, report a better team learning and feel more motivated and less stressed.

Many professions evolve from their origins as a creative craft process to a more product-centered industrial process. Software development is on such an evolutionary trajectory. A major step in this evolution is the progression from ad hoc to more rigorous evidence-based decision-making in software development project management. This paper extends theory and practice in relation to lean software development using such an evidence-based approach. Based on a comprehensive dataset of software development metrics, gathered in a longitudinal case study over a 22-month period, the Erlang-C model is used to analyze different software development parameters and to guide management decision-making in relation to development resources. The analysis reveals how 'gut-feel' and intuition can be replaced by evidence-based decision-making, and reveals how incorrect assumptions can underpin decisions which as a consequence do not achieve the desired outcome.