Eero Laukkanen

Stakeholder Perceptions of the Adoption of Continuous Integration -- A Case Study

Continuous integration is an important support mechanism for fast delivery of new features. However, its adoption in industry has often been problematic, partly due to social challenges. However, there is little knowledge of the exact nature of the challenges, and how different stakeholders perceive the need for and adoption of continuous integration. In this paper, we describe how the introduction of continuous integration was perceived by different stakeholders in a R&D program at Ericsson. The case provided a rare opportunity to study the adoption of continuous integration in a large distributed organization. We interviewed 27 stakeholders and found differing perceptions of continuous integration: how suitable it is for the organization, how adoption should be organized, and whether it is possible to achieve sufficient quality through automated testing. These differences of perception were mainly consequences of the geographic distribution. Based on the case study, we propose three guidelines. First, understand that the product architecture has a significant effect on the adoption. However, do not let architectural problems keep you from implementing continuous integration. Second, give the team members sufficient time to overcome the initial learning phase in the adoption. Third, avoid centralizing competencies to individual sites, and invest in cross-site communication.

Problems, causes and solutions when adopting continuous delivery—A systematic literature review

Abstract Context: Continuous delivery is a software development discipline in which software is always kept releasable. The literature contains instructions on how to adopt continuous delivery, but the adoption has been challenging in practice. Objective: In this study, a systematic literature review is conducted to survey the faced problems when adopting continuous delivery. In addition, we identify causes for and solutions to the problems. Method: By searching five major bibliographic databases, we identified 293 articles related to continuous delivery. We selected 30 of them for further analysis based on them containing empirical evidence of adoption of continuous delivery, and focus on practice instead of only tooling. We analyzed the selected articles qualitatively and extracted problems, causes and solutions. The problems and solutions were thematically synthesized into seven themes: build design, system design, integration, testing, release, human and organizational and resource. Results: We identified a total of 40 problems, 28 causal relationships and 29 solutions related to adoption of continuous delivery. Testing and integration problems were reported most often, while the most critical reported problems were related to testing and system design. Causally, system design and testing were most connected to other themes. Solutions in the system design, resource and human and organizational themes had the most significant impact on the other themes. The system design and build design themes had the least reported solutions. Conclusions: When adopting continuous delivery, problems related to system design are common, critical and little studied. The found problems, causes and solutions can be used to solve problems when adopting continuous delivery in practice.

Improving the delivery cycle

Context: Software companies seek to gain benefit from agile development approaches in order to meet evolving market needs without losing their innovative edge. Agile practices emphasize frequent releases with the help of an automated toolchain from code to delivery.Objective: We investigate, which tools are used in software delivery, what are the reasons omitting certain parts of the toolchain and what implications toolchains have on how rapidly software gets delivered to customers.Method: We present a multiple-case study of the toolchains currently in use in Finnish software-intensive organizations interested in improving their delivery frequency. We conducted qualitative semi-structured interviews in 18 case organizations from various software domains. The interviewees were key representatives of their organization, considering delivery activities.Results: Commodity tools, such as version control and continuous integration, were used in almost every organization. Modestly used tools, such as UI testing and performance testing, were more distinctly missing from some organizations. Uncommon tools, such as artifact repository and acceptance testing, were used only in a minority of the organizations. Tool usage is affected by the state of current workflows, manual work and relevancy of tools. Organizations whose toolchains were more automated and contained fewer manual steps were able to deploy software more rapidly.Conclusions: There is variety in the need for tool support in different development steps as there are domain-specific differences in the goals of the case organizations. Still, a well-founded toolchain supports speedy delivery of new software.

Bottom-up Adoption of Continuous Delivery in a Stage-Gate Managed Software Organization

Context: Continuous delivery (CD) is a development practice for decreasing the time-to-market by keeping software releasable all the time. Adopting CD within a stage-gate managed development process might be useful, although scientific evidence of such adoption is not available. In a stage-gate process, new releases pass through stages and gates protect low-quality output from progressing. Large organizations with stage-gate processes are often hierarchical and the adoption can be either top-down, driven by the management, or bottom-up, driven by the development unit. Goal: We investigate the perceived problems of bottom-up CD adoption in a large global software development unit at Nokia Networks. Our goal is to understand how the stage-gate development process used by the unit affects the adoption. Method: The overall research approach is a qualitative single case study on one of the several geographical sites of the development unit. We organized two 2-hour workshops with altogether 15 participants to discover how the stage-gate process affected the adoption. Results: The stage-gate development process caused tight schedules for development and process overhead because of the gate requirements. Moreover, the process required using multiple version control branches for different stages in the process, which increased development complexity and caused additional branch overhead. Together, tight schedule, process overhead and branch overhead caused the lack of time to adopt CD. In addition, the use of multiple branches limited the available hardware resources and caused delayed integration. Conclusions: Adopting CD in a development organization that needs to conform to a stage-gate development process is challenging. Practitioners should either gain support from the management to relax the required process or reduce their expectations on what can be achieved while conforming to the process. To simplify the development process, the use of multiple version control branches could be replaced with feature toggles.

Do high and low performing student teams use Scrum differently in capstone projects

In this paper, we present how student teams appliedScrum in their capstone projects and compare how the Scrum usage differed between the high and low performing teams. 16 student teams of 7–9 persons were taught Scrum during a lecture and a 4-hour Scrum simulation game, after which they applied Scrum in their capstone projects developed for external industrial customers during a six month period. We collected data by surveys (98 responses) and by interviewing all 16 teams at the end of the course. Our results show that the frequency of Scrum practice usage does not differ significantly between the low and high performing teams. However, the interviews showed that the high performing teams applied Scrum practices more thoroughly, e.g., by taking better advantage of the retrospective meetings and Daily Scrums and working more face-to-face, while low performing teams paid less attention to the proper way of applying the Scrum practices.

Comparison of release engineering practices in a large mature company and a startup

Modern release engineering practices provide multiple benefits for software companies, but organizations have struggled when trying to adopt the most advanced practices, such as continuous delivery. It is not known in which contexts the most advanced practices are applicable and what can be achieved by adopting them. In this study, we discuss the effect of the organizational context on adopted release engineering practices and what outcomes are achieved with the practices. We study two organizational contexts: the startup and the large mature company context. The effect of the product context is mitigated by studying two case organizations with similar products, a rare research opportunity. We performed 18 interviews with various roles in the case organizations. The number of production environments, the number of customers, the control over the production environment, the available resources, the organization size and the distribution of the organization affected the release engineering practices and the ability to release frequently. Having less internal verification and more customer verification enabled fast feedback and customer experimentation in the startup context, but increased the number of production defects. However, having more internal verification in the large mature company context surprisingly did not prevent production defects. The organizational context had a large effect on how achievable modern release engineering practices, such as continuous delivery, were. In the startup context, the lack of resources was the main factor hindering the improvement of release engineering practices, while in the large mature company context, the number of stakeholders and products were the main factors.

Towards continuous delivery by reducing the feature freeze period: a case study

Today, many software companies continuously deliver and deploy new features to their customers. However, many software systems are still released traditionally with long feature freeze periods and time-based releases due to historical reasons. Currently, only a few empirical inquiries of transformations towards continuous delivery exist. In this paper, we aim to understand how feature freeze was practiced and the feature freeze period reduced in an R&D program at Ericsson. The case organization has struggled with the feature freeze approach and is now moving towards the continuous delivery paradigm. We investigated the intended and actual effects of the feature freeze practice, how the feature freeze period was reduced and what effects the reduction had. We interviewed 11 employees, covering all the development teams at the largest site of the distributed organization. In addition, we analyzed data from software repositories to get quantitative triangulation of the qualitative results. Historically, the organization was not able to comply with the intended feature freeze practice, due to pressure for new feature development and long feature freeze periods leaving little time to perform actual development. By implementing test automation, the organization was able to reduce the feature freeze period by 56%, after which the amount of changes during the freeze decreased by 63% and the amount of changes close to the release date by 59%. We conclude that reducing the feature freeze period is possible using test automation, and reducing the freeze time can increase conformance to the intended feature freeze practice. To further reduce feature freeze, attention must be paid to deployment automation and collaboration between development and operations, in addition to test automation.