Summary of three short stories of technical debt

The presenter was Bruno Morel from SeedBox. He talked about 3 methods to reduce technical debt that he has tested in his career so far.

The technical debt

First of all, the technical debt, in the framework of the development of a project, is inevitable. If nothing is done, it will increase rapidly. This has the impact of increasing the number of development hours required to maintain the application.

Technical debt is at several levels:

• The architecture of the project did not follow the evolution of the project
• Tests are more and more difficult to maintain
• The deployment process is complicated
• The application frameworks used in the project are outdated.
• The team does not have time to explore (either to test new tools or to test new development techniques).

Here are 3 solutions that have been tested by Bruno and their results.

Solution 1: A technical debt sprint

Concept

For every X sprints (for example 4 sprints), the team does a sprint where no new functionality will be delivered. The sprint is entirely dedicated to debt reduction.

Result

Easy to implement, but not so satisfying. For the Product Owner it implies that during a full sprint the project does not seem to be advanced. During regular sprints, some tasks are done quickly by the developers thinking that there is the technical debt sprint to improve the whole thing. During the technical debt sprint, the team is not able to fix everything, which has a negative impact on motivation in addition to not having time to explore. Even though it is better than doing nothing, the debt continues to increase.

Solution 2: Specialists with continuous improvement

Concept

Each team member chooses a specialty (front-end, back-end, Build server, ...). At each sprint, a portion of the time (for example 15%) is reserved for each specialist (or team of specialists) to reduce the technical debt in his specialty.

Result

Better than the first solution, but it's not perfect. The PO likes it because the software is constantly progressing. The problem is that there is an imbalance of debt because of the specialties. For example, he may have very little technical debt in the back-end but a big debt in the deployment process.

In the end, there is always a growing debt.

Solution 3: Software improvement (without specialist)

Concept

This solution is similar to the previous one except that there is no specialty. The team chooses what to tackle and it is the responsibility of the team to do so.

Result

La dette technique reste au minimum. Le PO est toujours content, car l’avancement du projet est constant. Puisque la dette est au minimum, les développeurs ont même le temps de faire un peu d’exploration. Par contre ça demande une bonne discipline de l’équipe pour prendre le temps de faire l’amélioration logiciel et de faire les bons choix de quoi améliorer.

How to manage software improvement

The method used to manage priorities is through monthly meetings where the development team prioritizes the tasks to be done to reduce the technical debt. During the "sprint planning" the technology debt tasks are not planned or evaluated. On the other hand, the sprint is planned according to keeping 15% of free time to make continuous improvement. The developers decide when, in the sprint, they will make continuous improvement. When tackling continuous improvement, it is the task of the developer to take the task according to priority. It should not exceed 15% of the sprint time.

We can say that software improvement is managed in Kanban mode within a Scrum process.