Keywords

1 Introduction

Managing technical debt is reportedly non-trivial tasks for project managers and team leaders in software development projects. Technical Debt (TD) is a metaphor for a work-around technical solution that is not sustainable and requires future rework [1]. It has been shown as an important phenomenon to expedite the development in the short term in both large companies [2] and small and startup companies [3]. Technical Debt Management (TDM) is a process that includes different activities such as identifying, measuring, monitoring, prioritizing, and repaying TD. It has been adopted by some large software companies, but at different levels of maturity [2, 4]. Although TDM is important to proactively manage the risk of TD, it introduces extra activities to the regular development which leads to extra costs [2, 5]. Consequently, many companies (especially the ones with limited resources) would find TDM difficult to adopt as part of their development process. Furthermore, it is difficult to identify and manage large instances of TD items in agile software development [6].

Managing technical debt is not independent from other aspects of project management and the project development life cycle. When it is managed, TD is often treated as a task in the product backlog along with other tasks such as new features and bug fixes. Measuring and prioritizing TD in the product backlog depends on the evaluation of its negative impact on the product. Some negative impacts of TD has been found from literature, for instance, delaying the delivery of releases [7], increasing the number of maintenance activities [8], and reducing the team productivity [9]. However, knowing the negative impact of TD is only one half of the story. Agile project managers need a precise way of measuring this impact, to better communicate it to other stakeholders.

In agile projects, there are possibilities with using agile productivity metrics, such as velocity, cycle time and takt time [10, 11] for measuring TD implications. Sprint velocity is among the most common productivity metrics in agile projects that use Scrum method [10], by showing the number of tasks (i.e., story points) that the team can accomplish in one sprint. Cycle time is defined as the amount of time that passed from when work actually started to fulfilling the work [12]. Takt time is defined as the average time interval between the start of development of two sequential software versions to meet customer demand [13, 14]. This measure helps to identify if the software team can meet the customer demand, exceeding the demand (over producing) or unable to meet demand (under producing). To the best of our knowledge, there is no study that connects the agile team productivity metric with the TDM process.

In this paper, we propose a lean approach for TDM by incorporating the usage of agile productivity metrics within the TDM process. This lean approach is used specifically for TDM within the agile software development methodology. In general, lean is an approach that focusses on delivering maximum value with minimum waste. Our approach is “lean” in a way that emphasizes on minimizing the effort and complexity of TDM, by focusing on monitoring and addressing TD implications quantitatively. This can facilitate the adoption of TDM by 1) providing a lightweight approach for TDM in agile software projects, and 2) bridging the communication gap between technical and non-technical people for decisions related to allocating resources for TDM. We conducted a short survey of 43 software product and project managers to initially evaluate the concept of our approach. The results reveal that most project managers foresee potential advantages of our approach.

2 The Lean Technical Debt Management Process

2.1 The Management Approach

The proposed approach introduces a new paradigm of dealing with TD. Based on this approach, TDM is driven by a popular metric in agile project management such as sprint velocity. In addition to its usage for measuring the development velocity, we use this metric as a quantitative measure for TD implication. Since dealing with TD involves high uncertainty about its future impacts (i.e., difficulty to measure TD interest), TDM is proceeded based on a control threshold of the development velocity.

Our approach applies a lean mechanism that simplifies the way of dealing with TD. It assumes that issues that directly affect the development velocity are considered TD issues. This assumption is based on evidence from previous studies that TD can be manifested in multiple aspects (beyond software code and architecture) such as process, people, social [11, 15]. Also, TD related to process and people are found to be more interested to project management practitioners [16]. In addition, the development speed (i.e., delivery speed) is identified as the most common effect of TD [7].

Figure 1 shows our lean approach for TDM. It connects some project management activities (PM layer) with TDM activities (TDM layer). At the PM layer, the agile project managers monitor the team velocity at the end of each sprint using some metrics (e.g., sprint velocity) which is usually available in the PM data. In addition, the project managers need to establish control thresholds for the velocity that determine the optimal velocity range. At the end of each sprint, the project managers check the variance between the actual and optimal sprint velocity. If the actual velocity is below the optimal, then the project managers can measure the impact of such low velocity by calculating the difference (i.e., TD interest). The following formulas are used to measure velocity and TD interest:

$$ Actual \, \left( V \right) \, = \, Actual \, velocity \, of \, the \, current \, sprint $$
(1)
$$ Optimal \, \left( V \right) \, = \, MD\left( {optimal \, velocity \, range} \right) $$
(2)
$$ Current \, \left( {TDI} \right) \, = \, Optimal \, \left( V \right) \, {-} \, Actual \, \left( V \right) $$
(3)
$$ Future \, \left( {TDI} \right) \, = \, Current \, \left( {TDI} \right) \, * \# \, Planned \, release $$
(4)

where V indicates Velocity, MD refers to Median, TDI stands for TD Interest, and # is the Number of future released to be considered in the prediction.

Since our approach is driven by TD implication (which is measured using the development velocity), It begins by measuring TD interest before identifying TD items. The TD interest is precisely measured for the present as the difference between current and optimal velocity (step 2.1 in Fig. 1). After that, the TD interest can be estimated in the future considering the most recent TD interest and the number of future releases/sprints that captures the future timeframe (step 2.2 in Fig. 1). This information can help project managers to communicate with non-technical stakeholders (e.g., high management or investors). It also supports decision making related to allocating resources for TDM. If the non-technical stakeholders decided to spend resources for TDM, then the project managers can begin the process of TDM (i.e., move to the TDM layer). If not, then the project managers will remain on the PM layer and continue 1) monitoring the development velocity, and 2) informing the non-technical stakeholders about the velocity variance and its related TD impacts.

TDM layer includes the main TDM activities [4], which are proceeded after the agreement to allocate resources for TDM. This layer includes some TDM activities such as TD identification (step 3 in Fig. 1), TD measurement (step 4 in Fig. 1), TD prioritization (step 5 in Fig. 1), and TD repayment (step 6 in Fig. 1). The TDM layer is adopted from the TDM frameworks in [4, 17]. However, we eliminate activities such as TD monitoring and TD prevention since our approach concentrates on monitoring TD implications (not TD items). Also, our approach applies a different mindset for TDM that is driven by a control threshold of TD implications (with less emphasis on TD prevention). In the TDM layer, the project managers begin the TDM process by identifying TD items which are (according to our approach) the causes that are directly associated with the velocity reduction. Then, TD items are measured as the cost of fixing each item (i.e., TD principal). After that, TD items can be prioritized based on their fixing cost and their impact on the development velocity. Finally, TD repayment is performed starting from TD items with highest priority.

Fig. 1.
figure 1

Lean TDM process

Full size image

2.2 Use Scenarios

Table 1 shows an example of how the lean TDM approach can be applied. In this example, we classified the development velocity into three risk levels: low risk, moderate risk, and high risk. The low-risk indicates the optimal speed range based on the company’s goal. At this level (low risk), the team can confidently skip TDM. It means that it is not efficient to allocate resources for TDM since no symptoms appears. When the speed is at the moderate-risk range, it is an indication for early TD symptoms. At the moderate risk level, the team needs to keep non-technical stakeholders informed about this early TD symptoms and their impact by calculating the TD interest as the difference between current and optimal/planned speed. This high-level of measuring TD interest considers the observed (fact) consequences of TD that is the gap in the development speed. In case the optimal speed is determined based on a range of value, the median value of the optimal range can be used to compare with the actual value.

In addition, the lean TDM approach can be used to provide a guidance (recommendation) for decisions to allocate resources for TDM. For example, at optimal velocity range, the recommendation would be spending resources on TDM is not mandated. When reaching the moderate range, it is recommended to allocate resources for TDM, but TD repayment is optional or can be partially implemented. At the low velocity, TD repayment is needed. Based on this example, the team should not wait until reaching the low velocity. But rather proactively informing the high management about TD consequences when reaching the moderate range, using precise fact-based measures of TD interest.

The example in Table 1 is used only to illustrate one way of applying our approach. But it is flexibale for any context to select its own metric and control threshold for the development velocity. At the end, the overall concept is the same that to have a common control threshold for the development velocity that is applied within the team, and such a threshold drives the TDM process and TD interest measurements.

Table 1. Lean TDM Approach at PM Layer – An Example.
Full size table

3 Empirical Validation

To initially validate our proposed lean TDM approach, we surveyed 43 software project/product managers from different software companies around the world. We targeted software project/product managers because our approach focusses on the project management activities. For example, seeking resources for the product from other stakeholders is the main role for the project/product managers. Sampling of this population was performed using convenience sampling method [18]. In addition, we recruited some participants (22 out of 43) from a professional recruitment channel, which is ProlificFootnote 1.

The survey instrument is available in our supplemental materialFootnote 2. It is a short survey that primarily intended to communicate and get feedback about our lean TDM approach. It consists of three sections. The first section presents a brief explanation about our idea to participants, and shows a table that illustrates our idea. The second section includes some questions that characterize the participants, such as company location, company size, and years of experience in the project/product management role. Finally, the third section asked respondents to initially evaluate our idea based on three technology acceptance metrics from TAM (Technology Acceptance Model) [13], which are perceived ease of use, usefulness, and predicted future use. Before disseminating the survey, we validate the survey internally that each author read the survey’s questions and provide his feedback. At the end, we conducted a consensus session where we discuss the comments and reach consensus about the survey.

A total of 43 participants filled the survey. Figure 2 shows the characteristic of our participants. Most of the participants works in companies in Europe with less than 5 years of project management experience. In terms of company size, our participants work in different sizes of company, but most of them in small companies.

Fig. 2.
figure 2

Characteristics of participant

Full size image

Figure 3 summarizes the participants’ opinion on our proposed approach. It presents their answers to the closed questions in the third section of the survey (TAM related questions). On average 61.6% of the respondents perceived that the proposed approach would be easy to use (strongly agree or agree). In assessing the usefulness, on average 79.05% of the respondents strongly agree or agree that the proposed approach would be useful for project managers. Finally, on average 54.7% of the respondents strongly agree or agree that they will use the proposed approach in future to manage TD.

Fig. 3.
figure 3

Results of the initial evaluation to lean TDM approach

Full size image

Some participants reported in the open question that the proposed approach is more helpful for an organization with very limited resources. For example, small organizations or startups usually do not have dedicated quality assurance roles. This kind of organization often relies on external support (e.g., consultancy agency) when such quality assurance is required. However, other participants were a bit skepticism as the actual usefulness and ease of use could only be predicted after using the proposed process. The dataset is available in our supplemental materialFootnote 3. In sum, this initial results provides early insights into the potential usefulness of our approach by software project managers.

4 Discussions

Previous work proposed different TDM frameworks and strategies to encourage the use of TDM in practice [19, 20]. Other studies introduced different techniques to support software teams to perform specific TDM activities, such as TD identification [21], TD measurement [22], TD prioritization [23]. However, most of the previous studies focus on TDM from certain dimensions (e.g., code, design, and architecture, etc.). Since TD is a multidimensional phenomenon, it can be difficult to have a framework that manages all aspects of TD. What distinguish our paper from previous work is that it addresses the multidimensionality of TD by increasing its level of abstraction. That we consider TD as issues that are associated with the development speed. We think that this approach can simplify the adoption of TDM in practice. It can also amplify the communication bridge between TDM and agile PM activities.

4.1 Threats to Validity

There are four main limitations in our approach. First, we assume that all issues contributed to the reduction of development velocity are considered TD. Although this assumption might simplify the adoption of TDM, it can introduce a risk of including some issues not related to TD. To address this risk, we plan (in our future work) to add a risk factor in our equation to account for this risk. Second, our approach depends on existing metrics that are used to measure team velocity. We assume that project managers have an existing metric in place related to team velocity. However, a metric such as team/sprint velocity is found to be a common one in agile software project management [10] which can minimize this threat in the agile software development context. Third, the process of identifying TD items (step 3 in Fig. 1) depends on people experience and how thoughtful they investigate the issues that cause the development speed reduction. So, the quality of TD identification depends on people experience. Lastly, we recruited some participants using Prolific, a professional channel for research participant recruitment. Despite the limitation for its lack of explicit design, it has emerged as a viable and cost-efficient option for researchers [24].

5 Conclusions

The application of TDM in practice remains limited especially in organizations with limited resources (i.e., those organizations that do not have a mature quality assurance team). In this paper, we proposed a lean approach to facilitate the adoption of TDM in such organizations. Our approach introduces a new mindset for managing TD that is driven by TD implications/symptoms (primarily the velocity of development). It introduces an alternative way of measuring TD interest, which is based on fact-based consequences of TD (i.e., the gap between the actual and planed development speed). We sent a short survey to software project/product managers to get their initial feedback about our approach. The majority of them have positive expectations for our approach. For future work, we plan to perform a longitudinal case study, which includes interviews at different points of time, to empirically validate and refine our approach.