Ah, technical debt, the arch enemy of all projects! It is polymorphous, invisible, and insidious. It’s even a taboo subject for many people, while we, Agile coaches and Scrum Masters, make a point of honour of addressing it frequently.
Do you know your teams’ technical debt? Can you describe it? Above all, are you trying to reduce it? In this post, I reflect on how you can win a few battles about it.
What’s that?
In software development, there are numerous definitions for technical debt. To remain concise, I consider it as an accumulation of tasks required to guarantee an end product that is reliable (i.e., operational and maintainable over time). This together with a rigorous definition of “done”, which describes the qualities your deliverables must respect.
This debt results from the development team’s technical or organizational activities and decisions as well as from their quality that evolves over time. The form and extent of the debt are, therefore, different from one project to another. Always there, it tends to increase exponentially if we do not address it properly. Consequently, its complete elimination is impossible, but it remains essential to regularly assess it and take action in order to minimize it.
You’ll know everything about technical debt…
What is it made of? Here are a few items:
- Quality and content of specifications (clarity, just-enough)
- Number of tests and their purpose (coverage, relevance)
- Coding conventions (maintainability, compliance with standards)
- Proper use of design concepts (SOLID, …)
- Implementation of a feedback reporting and integration framework (automation, frequent conversations)
- Technical, functional, and user documentation
- …
Noticeable signals and measurable impact are numerous:
- User dissatisfaction expressed after delivery or during review (non-acceptance)
- Increasing ratio between the duration of a delivery and item complexity
- Number of bugs and incidents identified over a given period of time
- Duration of legacy code, product, or component investigations
- Dependency of the team of experts (bus factor)
- Overtime of the development team working under pressure
- Score given by the development team concerning the fun and pleasure they have working on the project
- Need for training and tools
- …
The perfect pitch
It is not uncommon to see the technical debt rise high up; reaching a level that is unacceptable, but not necessarily a point of no return. This moment is critical. The outcome will depend on the decision made by the team. Do we keep going without changing a thing? Do we apply a patch or do we tackle the problem to the root?
Numerous factors must be taken into account and, paradoxically, the necessity to respond to emergencies while delivering items that are “done” lead to the decision to address technical debt superficially… or not at all.
Here are the causes: resistance to change, ease to take the usual default option, a miscalculated or non-existent ROI measurement. If, by common sense and courage, you decide to put an end to it, I congratulate you!
What if I choose the wrong path?
I invite you to start assessing the impact of technical debt. For now, if you do not have factual information in hand, I suggest that you simulate it during a workshop or retrospective.
Put the finger where it hurts and find the cure.
First of all, with your team, identify the strongest factor in the current debt and find how it can reduce it in the most direct manner. If the exercise proves difficult, the 5 whys are very useful to find the source of the problem; i.e. the opposite of remedy. ..
Scale ingredients and adjust the dose.
It’s from this point that you can use the recorded measures. Quantify technical debt according to the factor. Then, quantify the breach that should have been committed by the team or what could be done against it. If these measures already exist, you’ll be able to make a finding based on your experience. Otherwise, project yourself into the present or future, even if you have to perform a simulation using estimations that are more or less realistic.
This exercise can take a few hours, but it’s really worth it.
Here is an example of a fictitious but realistic project:
The project contains a certain number of critical bugs that are reported upon each increment delivery. No one knows the product’s total cost of ownership. However, thanks to her experience, one of the developers was able to calculate the maintenance cost and the effort to be deployed. Tests have not been run yet because of a lack of pressure on the team as well as of a lack of expertise. Yet, if we applied ourselves to doing it, the activity should be less difficult over time. Let’s approximate the losses resulting from the lack of tests on the functions implemented.
What does this example allow us to realize? Yep, it’s true, in the short term, it is pricey to rule out technical debt by taking more time to write tests and maintain their framework. However, as soon as we’ve finished and delivered 26 functions with discipline, rigour, and test coverage, the debt accumulation is almost reduced to zero and goodbye to financial losses! Therefore, there are no reasons for continuing to neglect tests.
Know what? The sooner you’ll take action, the most beneficial it will get. Note how the gap increases at the bottom of the chart. …
Follow the prescription carefully to heal properly
After making your own findings, making better decision and following a new course of action will come more naturally. Have the courage and state of mind to get rid of debt, even though you get results only after a few weeks! Track your progress to stay motivated… and appreciate any small victory.
Conclusion
More than one battle is required to win a war, especially when the enemy is as colossal and complex as technical debt. However, in the end, victory is appreciated even more and it is particularly rewarding.
For you, what is the face of technical debt? What is your action plan for getting rid of it? Share your victories with us!
No Comment