What have you found to be the best approach to technical debt management?
Sort By:
Oldest
CIO in Energy and Utilities3 months ago
I think the key is not to ignore it, and assume that most if not all IT projects will have some form of technical debt. We take this into account and address it in sprint planning. We have specific stories and epics in Azure Dev Ops related to technical debt and address them in each sprint as part of the work that needs to be done. CTO in Healthcare and Biotech3 months ago
Pay tech debt as you would be paying debt on credit cards.Let's imagine that you have 3 credit cards, in all of them you have interest you must pay. So choosing the credit card with the highest interest is the first one you should clear out ( And cancel as well ). Then you'll move to the following credit card with the highest interest, and repeat the same process.
It happens the same with tech debt that you have, you must first choose the tech debt that either is most important for the business or to your department. What you'll do is finish that specific tech debt getting as many resources as possible to finish it. Then you'll go to the next tech debt, repeat the process, and that way you could mitigate tech debt.
Head of Transformation in Government3 months ago
Avoid it, but once it's there...1. map it, cost it and report it regularly to the senior management
2. include it in annual project proposals, or if in a product management mode with agile, create and fund a team to work it down
3. ensure an architectural governance that interrupts business benefit proposals and requires them to resolve the underlying technical debt before piling more weight on top.
Use FUD - especially security risks for both legacy and technical debt.
CIO / Managing Partner in Manufacturing3 months ago
Spot on, my thoughts exactly.
Also worth, understanding the true cost of the technical debt, and using this in discussion with the business owners of the various areas.
VP of Technology3 months ago
I suggest avoiding technical debt entirely. Do this by creating a 5 or 10 year plan. In your plan, identify the most critical issues and prioritize them first by business impact and then by cost. Then add in the remaining needs. Submit your budget based off this plan, using your critical issues and their business impact as the justification. Limit technical expenses to the available budget without adding debt.If you already have technical debt, add it to your budget and pay it off based on the rotation of the equipment the debt was incurred for. You do not want to be paying for old technology after that technology has already been replaced.
So, have your team take on an approach of "leave each file/feature better than when you started." In other words, when an engineer sees the tech debt within a file/component/service, they should expand the scope of the project to fix the issue (i.e reduce tech debt) rather than work around it. Sometimes, this might mean change other unrelated files but the scope should be limited to fixing the bug or adding a new feature - lest it snowballs into a complete overhaul.
This should also be supported in the sprint planning or estimation process. Invariably the team has a sense of where the biggest debt areas are and so have them bake that into the estimate helps set expectations. Furthermore, code reviewers should look at changes from a debt reduction perspective rather than, "it passed unit tests", "it works on my machine" or our "LGTM" reviews... the standard of a code review must include debt reduction.
This approach takes longer and can be more uneven - which is the nature of tech debt in the first place... no one willingly writes debt-ridden code - there are very likely good business reasons for it: a critical bug that need a patch; a new feature getting to market faster, etc. These aren't bad reasons and often a little debt helps the company move forward and get things done. Implicit in this, is the assumption that your engineering team have the chops to do it the right way or they are willing to get help if they don't feel qualified.