Are you agile when plagued by technical debt?

16 March 2020

Man carrying boxes

Almost everyone claims to be agile. Some “in their way”, others more formally as part of a framework. From small startups to big automotive vendors and from development teams to HR, suggesting you are not agile is the equivalent of admitting you hate puppies or something equally shocking.

While agile is served as the panacea to all problems, this article is not about enumerating the different ways it has been butchered. Instead, we will focus on why it is difficult to attain what agile development promises: Value delivered to customers in small increments to maintain short feedback cycles. This facilitates rapid response to environmental changes and maximized alignment with the latest business needs.

Why do your agile projects fail then? Is it because you do not follow SCRUM, SAFe, LeSS or <insert methodology here> religiously enough? Is it that the top management has merely sprinkled waterfall with agile flakes instead of adopting the mindset?
Maybe so, but you are also burdened by the weight of technical debt.

Technical debt is a metaphor, coined by Ward Cunningham in 1992, describing activities you do not partake in and this is likely to create problems down the road. To bring this into perspective, how can you be agile and deliver value fast, when excessive amounts of changes are required for each new feature due to suboptimal architecture? Or when recurring bugs are devastating your user experience and the mechanism to ensure high-quality deliveries is just too cumbersome? You can simply not be agile when you are plagued by technical debt.

Alves, Nicolli SR, et al. (2014) in their work titled “Towards an ontology of terms on technical debt” have identified 13 types of technical debt in software projects. Some of the more common include:

  • Architecture & design debt
    • High coupling, no separation of concerns, lack of modularity, use of anti-patterns, commodity functionality depending on differentiating features
  • Code debt
    • Code smells, unreadable and highly complex code
  • Test & automation debt
    • Low code coverage, manual testing & deployment
  • People debt
    • Scarce and concentrated expertise, lack of shared knowledge

Selecting an agile framework is orthogonal to the emergence of technical debt. The framework may illustrate how to organize your project, distribute the roles and define the release process, but will not make the crucial choices for you as you are sinking in debt.
Consequently, how can you protect your project from being crippled by technical debt?

Technical debt is accumulated by choices which, knowingly or not, favor short term earnings over adverse consequences in the future. Therefore you should:

  • Acknowledge technical debt as one of the primary factors hindering your effectiveness, time-to-market, and innovation
  • Repay technical debt by providing your developers with the necessary resources
  • Educate project members to recognize decisions which increase technical debt

The former two are a matter of strategy, culture and ultimately the realization that the longer you avoid action the closer you approach your demise.

With the latter, Edument can help with our talented consultants and our courses on various programming languages, software architecture, Test Driven Development, Git and CI.

This article was originally published on edument.se.