Organizations must often decide whether to release a product earlier to accelerate the time-to-market factor or to release the best, smartest solution that has no open or pending issues but might take longer to release to market. They need to strike a balance between these two choices and design a plan for a quality release with the best time-to-market factor. In doing so, organizations may tolerate living with some of the known issues that might not be a priority at the time but have to be addressed in the long run. Known issues that remain in the backlog in the form of unfinished work are generally called technical debt
. In simpler words, technical debt is the difference between what was initially envisioned and what was actually delivered.
Technical debt depends heavily on whether it is associated with a new start-up project or with legacy products. Mature products have a lot of accumulated technical debt. Not all of this debt was deliberately added; it could be the result of simply not having anything better at the time the product was originally built. Typically, this accumulated technical debt for legacy products forces organizations to spend considerable time in reducing it rather than focusing on new feature development. This indirectly reduces the appetite to work on those new features that are crucial to keeping the business abreast of the latest market requirements and trends and also to remain competitive in the market.
Managing technical debt is critical to organizations with large code bases to make their products successful; they must handle a balancing act of keeping existing customers happy and attracting new customers. They must convince prospective customers to buy their products by either coming up with new features or enhancing existing features. If not properly planned and managed, technical debt can become a major blocker that can affect the organization's reputation in the long term and can have a huge impact on the existing and new customer bases. Technical debt plays a vital role in the ability to attract new customers, as they will always want to buy a product that is free of it.
Although different organizations adopt different strategies for dealing with technical debt, experience shows that the most successful way of tackling it is to budget for it in the release and in the iteration planning, as with any other budget. Quality metrics (e.g., trouble reports) collected regularly from customers can be an important factor when deciding how much of the total capacity must be reserved for technical debt reduction. Having a specific technical debt "bucket" in the product backlog, and addressing, it will certainly add value to customers in the long run.
One effective way to control technical debt is to prevent further accumulation. This is accomplished by creating buckets by estimating the average rate of debt discovered in the previous release cycle. This way, if the incoming rate of technical debt remains the same in the current cycle, the reserved bandwidth would ensure that the technical debt does not increase further.
In addition to focusing on reducing accumulated debt, organizations might encourage teams to develop a process in which a review and an update to the Definition of Done is done regularly to prevent the accumulation of debt in the first place.
After having decided to reduce or eliminate technical debt over time, organizations face another major challenge: prioritizing it. Any technical debt reduction must be justified. Is it worth the effort and does it really benefit the customer, or does it increase business prospects for the organization? A good strategy from product management is essential in evaluating true debt versus structural improvements. That way, the strategy can be effectively prioritized for giving the highest value to the organization today and in the future. A variety of items, such as enhancements to existing functionality or changes to the underlying architecture, can surface throughout the project's life cycle, which may seem important from the developer's perspective. Product management must therefore constantly strike a balance while prioritizing these items, to determine whether it's necessary to pull an item into the backlog or whether it can wait for some time.
It is difficult, if not impossible, to remove all technical debt, especially in organizations that have a high volume of legacy code. Given today's highly competitive market, and to ensure the organization's long-term success and survival, product managers must have a clear road map that includes a sound plan for simultaneous investments in both innovation for new features and improvements to existing products.