Let’s talk a bit about technical debt. There will be some theory, but I hope this article won’t be against my Manifesto. I’m still aiming to give you practical tools for discussion and to explain why and how to manage the technical debt.
What a technical debt is then?
There are plenty of definitions you can easily find on web. Some of them are very narrow – like the one on Wikipedia: “Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer”. Some are very broad and divide technical debt into various categories such as: Code, Design, Documentation, Defects, Technology, Business, etc.
In this article I would like to consider technical debt as a difference between the current state of a system and the ideal system, having the same set of functionalities.
No matter which definition you use, I believe there’s one thing everyone would agree with – the more technical debt we have in the system, the higher is cost of its maintanance and further development. Presenting it on a chart, it will look like below:
The base cost is a cost of developing new feature in an ideal system. When the level of technical debt increases, the cost of developing a new feature will grow as well.
If you won’t control your technical debt level it may cause so much increase in the cost of new features that further development will become imposible.
How much the quality costs?
You should always have at least one stakeholder focused on quality. In Scrum this can be the Development Team (see more here: quality vs quantity). Wouldn’t everyone like to keep their IT systems of excellent quality? They surely would, but nothing’s for granted – the better quality you would like to reach, the more you need to pay. Putting this on a chart, we’ll see it as follows:
The more technical debt you have, the less you will pay for quality improvements. The less technical debt you have, the more expensive increasing the quality further will be.
Having a system with no technical debt (ideal one) would cost you infinite amount of money.
Technical debt management
Now let’s combine two charts into one and try to use it for making decisions. Remember:
- more technical debt = less quality
- less technical debt = more quality
First, assuming we have a system of high quality:
In this system the cost of further removing technical debt is much higher than adding new features. So it is wise to focus on new features delivering business value for customers in short term. Adding new features will of course create some new technical debt (missing documentation, test coverage lower than expected, some shortcuts in code, etc.) which will in turn decrease our quality a bit. So we will move accordingly to green arrows.
Second, assuming we have a system of low quality:
In such system the cost of removing technical debt is lower than adding new features. So it is good to focus on improving system quality (by decreasing technical debt), which will increase our development capacity in long term. Decreasing technical debt will improve quality and decrease cost of new features development (again, move accordingly to green arrows).
Conclusion
After combining these two decisions – invest in new features development or in the system quality – in one chart, you will notice that you will be oscillating in proximity of the cross point.
When the cost of adding new feature is too high, you switch priority and focus on quality (removing technical debt). When the cost of further quality improvements is too high, you change focus to new features development.
Balance between short and long term goals – delivering new features vs investing in quality – is crucial. The best approach is to work on new features and quality simultaneously.
Keeping in mind that every new development increases the technical debt, you should always remember and work on quality at the same time. If you have proper balance, your oscillation will be very narrow, maybe event not noticeable – you will be always in the cross point. If you don’t have balance then you will waste time, effort and focus on switching between quality and new features. Symptoms showing that can be: developers fighting for quality initiatives, refactoring or technical Sprints, stabilization phases and similar.
What is my technical debt level?
As you probably noticed for proper technical debt management you need to know where you are – what is your technical debt level and how it is changing.
Without proper knowledge you won’t be able to find cross point and stick to it.
I strongly encourage you to do short workshop with the development team, focused on defining proper metrics for technical debt measurement. Below is a timeline and description of workshop which I did in my team. Feel free to use it and share your experience and conclusions!
- [0-20 min] What the technical debt is? Write on sticky notes as many examples of technical debt as you can.
- [20-40 min] Let’s group sticky notes together into couple of categories. First group! Then try to name groups.
- [40-60 min] What are possible measures per each group. Brainstorming and sticky notes generation. Part 1.
- [60-70 min] Break. Football table in our case. 😊
- [70-90 min] What are possible measures per each group. Brainstorming and sticky notes generation. Part 2.
- [90-110 min] Let’s assess our ideas. Put all measures into two dimensions – value and usability vs. complexity and workload needed to set it up.
- [110-120 min] Choose 3-5 metrics and start using it for technical debt management.