In agile way of working, technical debt is still present as the team goes about completing stories based on definition of done.
What then exactly is technical debt ? This is the accumulation of previous known anomalies, which were not discovered previously before release. It can be in the form of bugs, design changes, code logic and even hard coding of parameters or values.
Technical debt usually has workarounds that satisfies the objective of the release without compromising the quality of the product. However, as time goes by, more and more issues / requests raised maybe related to one of the technical debts which may then need to be fixed.
It can be caused by multitude of reasons, some of which I will highlight and explore some examples below.
1. Shortcuts taken to meet deadlines : One of the examples would be system related configurations are kept as parameters in a database but sometimes this is easily forgotten as a nifty way to allow users to have self-service maintenance screens, rather than having everything done by the system administrator. Not important at first but as time goes by and more tickets come in for the team to configure these parameters, then its time to see if building this maintenance screens / pages is worth it.
2. Lack of knowledge or experience : Hard-coding pieces of functionality that otherwise could have been made more dynamic or placed into a centralized library is one of the common examples. This could be due to lack of expertise or experience and is commonly made by those junior members of the team. Hence, it is important for the team to perform peer code reviews, understand how the pieces of code came to be and how it can be improved on.
3. Poor design decisions : Scalability and adaptability is one of the direct impact of such design matters that pertains to the product. For example, in the initial stages of the product, it can be assumed to support a certain number of users. Once the use of the product became popular, the number of users may grow exponentially and result in decreased performance. Hence, the decision would be either to examine certain parts of the product, rebuild or enhance it further to ensure that the product can grow further to support more users. This can be in various forms such as monolithic vs micro services architecture, storage allocations, development framework etc.
What is the impact of accumulated technical debt ? While it may not have a short-term impact, but as time goes by, this can become a significant impact which will results in increased maintenance and complexity, reduced performance, inflexibility and higher risk. In the end, if left unaddressed, it can become unmanageable and result in poor product quality.
In Scrum, technical debt can be managed in a few ways :
- Prioritizing is an art and science : Based on past factual results and desired outcomes, address the technical items that are deemed critical without waiting too long. Discuss it with the technical team and determine the best route and effort to resolve it.
- Regular review and code refactoring.
- Training and development opportunities.
- Regular retrospectives.
- Technical debt items and tasks are converted into actual user stories.
In summary, increased and accumulated technical debt may result in degradation of the product quality in many ways. Hence , even if it’s not being addressed immediately, this should be kept in view in a list such as a Kanban board and be examined from sprint to sprint to evaluate and determine whether the resolution of some of this technical debt will result in a better product tomorrow.
Here are some other references to technical debt if you wish to know more :
https://medium.com/@somani.tarang/technical-debt-b1e8a6a95289
https://www.learnow.live/blog/how-do-scrum-teams-manage-technical-debt
https://www.planetcrust.com/how-to-solve-technical-debt
—————————————————-
Disclaimer: What I am sharing is purely from my point of view and experience working with various teams as a scrum master. It does not reflect anyone else’s opinion or endorses a framework.
What I present in my posts doesn’t necessarily mean that it is applicable to your work, organization and culture but I am glad if it aids you in your agile journey.
Sincerely and with many thanks for reading my articles, Jason.
