1. INTRODUCTION

Software Process Improvement is a widely studied area in software engineering. Finding systematic and efficient ways to produce software that effectively delivers business value to their customers, is one of the most important goals for software organizations. Clear examples have been the efforts in designing and adopting new processes, from the Waterfall to the V model to the most recent Agile trend [1]. Many new processes and activities are continuously proposed as the field evolves and new domains and products emerge. Software organizations need continuously to design and tailor new and efficient processes to guide their teams [2].
Consequently, several strategies and maturity models to assess software processes have been proposed (e.g. Six Sigma [3], CMMI [4]). Choosing a suboptimal process can lead to disastrous consequences. Several factors contribute to designing optimal processes or assessing improvement needs [5].
Nevertheless, what happens if the processes are not followed or are not well designed? In other words, how do organizations manage sub-optimal processes? Research and industry often provide new ideas on how to implement new processes, while knowledge of change management can assist in implementing them [6]. However, important questions need to be addressed, e.g. how to best prioritize the improvements of the processes that are already in place and how one may combine such improvement work with other pressing activities, such as delivering features to the customers and fixing bugs. Is process improvement perhaps down-prioritized in favor of such key activities? In other words, are companies accumulating Process Debt (PD), and if so, how do they manage such debt?
Recent research has brought quite a lot of new knowledge on the Technical Debt (TD) phenomenon to light, which characterizes sub-optimal technical implementations that give a short-term benefit but create a context where a long-term interest is paid. For example, we know that TD is very harmful and can account, on average, for a hidden 25% waste of development time in companies [7]. In addition, it negatively affects developers’ morale and software quality [8]. However, we do not have much information about PD. Is PD also similarly harmful, and how and why does PD occur? PD is a fundamentally different phenomenon from TD. Although in some preliminary papers PD was included as TD, the definition of TD achieved during Dagstuhl has remarked that PD is not part of TD (although some issues might be connected to each other).
Today, only a few studies (briefly) mention PD, e.g., the study by Li et al. [9]. In our recent study [10], when analyzing the topics discussed in software development teams’ agile retrospectives, it appeared clear that, besides TD, developers discussed several other non-technical issues that were deemed important for their performance. About one-third of the reported items were related to sub-optimal processes that needed to be fixed. In other words, they reported instances of PD that had a direct negative consequence to the developers and their work. Such study provides a preliminary definition, but without a full empirical investigation to support it.
In summary, PD, similarly to TD, is potentially a harmful phenomenon affecting software practitioners’ performance and the quality of software. Despite this, there is a knowledge gap about PD.
In this paper, we aim to address this gap by exploring PD through an empirical study by gathering experiences from practitioners in four international software companies. In particular, we investigated the following research questions:
RQ1: What is Process Debt?
RQ1.1: How can Process Debt be defined?
RQ1.2: What types of Process Debt exist?
RQ2: How does Process Debt occur?
RQ2.1: How is Process Debt accumulated?
RQ2.2: What are the causes of Process Debt?
RQ2.3: What causes are the most common?
RQ2.4: What are the negative consequences of Process Debt?
RQ2.5: What consequences are the most harmful?
RQ3 How can PD be managed?
RQ3.1 What mitigation strategies do companies use to manage PD? (results from interviews, longitudinal and workshop)
RQ3.2 What mitigation strategies are still missing to manage PD?
RQ4 Time dimension (results from longitudinal case study)
R4: How did PD change over time, and how was it managed?
First and foremost, PD needs to be understood and defined. This would help facilitate reasoning and provide a clear reference point of PD (RQ1). Then, we need to understand how PD occurs in practice, including causes and consequences, and which types of PD are more frequent and impactful. In other words, we need to understand the state of practice of PD (RQ2), which would help both recognize PD for practitioners as well as present a baseline to collect novel results in the future and develop novel techniques. In this regard, PD needs to be managed, which requires mitigation strategies to avoid, repay or mitigate the occurrence of PD (RQ3): we need to understand both the state of the practice, but also what is needed in the foreseeable future. Finally, we need to understand how PD occurs and is explicitly managed by looking at its evolution over time (RQ4).
The main contributions are:
The remainder of this paper is organized as follows. First, we outline existing key concepts, for example, related to software process improvement. Then we present our methodology, and we report the results in the same order as the RQs. Then we discuss the results, limitations and related work, and we conclude with our final remarks.