In product software development, technical debt is inevitable and will accumulate no matter what precautions are taken. Over time, technical debt can add up to more and more serious consequences, such as delayed delivery times, a significant number of defects, higher development and support costs, reduced predictability, reduced customer satisfaction, and so on.
Therefore, the management and repayment of technical debt is particularly important. Technical debt management requires comprehensive consideration of technical and business factors, so it cannot be separated from the participation of technical and business personnel. This is one of the reasons why each Scrum team should have a product owner.
In this article, three main activities of managing technical debt are described and how to repay technical debt.
Activity 1: Manage accrued technical debt
A key dimension of managing technical debt is managing accrued debt. There’s only so much technical debt we can take on before we reach critical mass, and by comparison, accumulated technical debt is like borrowing money from your family. At some point something must be done or there will be consequences.
| to use a good technical practice
The first way to manage the growth of technical debt is to stop adding low-level debt to the product. Using good technical practices is a great place to start. Code refactoring is an important debt reduction tool for accumulating technical debt. Code refactoring A canonical technique used to change the subject of existing code, adjusting the internal structure of the software without changing its external behavior. That is to clean up the inside of the software, from the customer’s point of view, the product works the same way.
We seek to improve maintainability and extensibility through refactoring, while reducing complexity. Refactoring makes the task at hand easier.
| use strong complete definition
Work that should have been done at the start of a feature build but was put off until later is an important source of technical debt.
The more technical details that are included in the complete definition checklist, the less likely you are to accumulate technical debt. The technical debt generated by the weak definition is often much higher than the cost of solving the problem in the sprint. Not forcing a definition is like giving the green light to technology accumulation.
Activity 2: Make technical debt visible
The main benefit of technical debt hiding is that it allows the development team and the business to have the necessary conversations in the same context.
| let technical debt at the business level is visible
The problem with many organizations is that the development team is more or less able to see what the technical debt of the product is, while the business people are clueless. In fact, it is critical that the business people see the technical debt status of the product, otherwise the business people will not know the true condition of the product and will not be able to make informed economic decisions.
| technical debt in the technical aspect is visible
Technical people often have tacit knowledge of where the most serious technical debt lies in the product. However, this understanding may not be visible enough to be analyzed, discussed and acted upon.
First, the technical debt can be recorded as a defect in the defect tracking system. The advantage of this is that the technical debt can be visible using known tools and techniques, and the team may choose to maintain the defect and technical debt in the same way.
Another way to make technical debt visible is to create a PBI for technical debt. Doing so makes important technical debt stand out as prominently as new features in the product list.
The team can often take this approach when the cost of servicing technical debt is high, and also requires the product owner to be involved in deciding how to prioritize it with new value-added features in the product list.
A third way to make technical debt visible is to ** create a special list of technical debts that clearly lists each one. Any time a new technical debt is discovered in the product or introduced, the development team can create a new technical debt entry and add it to the technical debt list.
By making technical debt visible, the development team can not only see the status of technical debt, but also proactively plan to repay it.
Activity 3: Pay off technical debt
The final activity in managing technical debt is debt maintenance or debt repayment. There are five main ways to repay technical debt:
- Not all technical debts should be repaid
- It also have debt
- Pay high interest technical debt first
- Repay technical debt in installments
- Pay off technical debt while doing customer value work
Technical debt repayment is important, but this does not mean that all technical debt should be repaid. There are two situations in which technical debt does not need to be repaid.
First, near the end of the product.
If a product has accumulated a lot of technical debt and is nearing the end of its life cycle, it’s not worth putting a lot of effort into paying it back.
If the value of the product is not high, let the product shelve delisting, and put resources into a higher value product. For products with high value and high technical debt, it is better to take on high risks and develop new products at high cost than to repay the technical debt it owes.
Second, short cycle products.
If you are building a product with a short life cycle, economics may not support the repayment of technical debt. No matter from the cost, market, profit and other aspects, enterprises usually do not make products that are expected to last only three months. In general, we prefer to develop products that can be sold for a long time.
The core of technical debt can be likened to a kind of debt, which needs to be paid strategically by the technical team to ensure the value of product delivery. Therefore, we can pay technical debt in the way of paying financial thinking.
For example, if there is a debt, pay it back in installments, and pay the big part of the debt first. By analogy with technical debt, our technical team can formulate corresponding rules. If we find occasional technical debt, we can timely clean up the technical debt, rather than placing it in defects or PBI.
If the debt is too large, the level of accumulated technical debt can be very high. In this case, we can pay known technical debt in installments and steps, rather than a lump sum later.
The advantage is that, similar to paying off a mortgage or car loan, pay off a portion of the debt each month to avoid paying the balance in one lump sum.
The same goes for technical debt, and while labeling all types of defects as technical debt is helpful, it is important to recognize that not all technical debt is equally important.
For example, in production, a module that is constantly being changed or called, on which a lot of other code depends, needs to be refactored as it becomes more and more difficult to change.
The team is paying interest on the debt, and the more modifications it makes, the more debt it soon becomes.
Therefore, when maintaining technical debt, we should first lock high interest technical debt and be maintained.
In addition, we can do customer value work and pay off technical debt at the same time.
| either way, you must make time for cleaning technology
Teams often struggle to find the time to pay off technical debt or clean up the costs of shortcuts they may have taken months or even years ago. Further problems arise when these defects are allowed to exist in the product. That’s why the metaphor of “tech debt” resonates so strongly.
Although I’ve outlined three approaches here, I prefer the fourth: avoid taking on any technical debt.
But that’s not always possible. Sometimes the team unknowingly takes on technical debt. So it’s important to have a repayment strategy for technical debt.
Jingzhou — Digital intelligence Lean Agile R & D management tool platform.
Whale Boat RESEARCH and development management
Agile R & D management platform suitable for Internet entrepreneurship team, now register to use, 30 people below the team, free forever.