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:
- a comprehensive framework to practically and theoretically reason
about PD, including:
- causes, consequences and types of PD
- occurrence patterns and evolution of PD over time
- a survey of the state of practice for PD management in five companies
- evidence of concrete instances covering each type of PD
- mitigation strategies to manage PD
- extensive validation of results by triangulating methods and sources
across contexts
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.