ScrumBut as an Indicator of Process Debt

Technical debt analysis is used to detect problems in a codebase. Most technical debt indicators rely on measuring the quality of the code, as developers tend to induce recurring technical debt that emerges along with evolution cycles. This debt can emerge when project pressure leads to process deviations, for instance. In agile methods like Scrum, such deviations are commonly known as ScrumButs (like Scrum but …), which can be considered as a form of process debt. In this paper, we investigate two recurring signs of process debt (i.e. code smells and anti-patterns) caused by Scrumbuts. Our contribution investigates typical ScrumBut practices found in agile projects in one company and we report the relationships found between problems in code and ScrumBut issues. Our findings identify three types of ScrumButs, their root causes, and how these relate to concrete code smells and anti-patterns.

I. Introduction

Daily changes made under pressure to software code is one of the sources of the appearance of code issues. Hence, the need for adding new features and fixing bugs in the codebase multiple times per day [1] is a recurrent problem that often leads to the appearance of technical debt [2] in its various forms (e.g. architecture or code debt [3] [4]). The appearance of technical debt in some software development contexts can exacerbate the frequency of the debt caused by bad design and programming practices. This is known as process debt [5] [6], which can be understood as a sub-optimal activity that might have short-term benefits but that generates negative consequences in a software project in the medium and long term. An example of process debt in the agile context is the appearance of ScrumButs [7], or deviations from baseline Scrum practices, explained by developers as ‘like Scrum, but [description of the deviation]’.