This article is a continuation of the previous article ‘The Hidden Cost of Technical Debt’. Here we discussed side-effects of accumulating Technical Debt.
Now as we have understood the problem, let’s discuss some possible solutions.
Some Techniques to Tackle Technical Debt
There could be two strategies to tackle Technical Debt.
- How to avoid accumulating new Technical Debt
- How to tackle it when it is already accumulated.
Strategies to Reduce New Technical Debt
Have a Comprehensive Definition of ‘Done’
Teams can reduce the Technical Debt creation by having a strong & comprehensive Definition of ‘Done’. It is a good practice to include Technical Debt related specifications in the Definition of ‘Done’. For example, ‘80% of Acceptance Criteria must be automated’.
Tip: Definition of ‘Done’ acts like a working agreement for the Development team. Development team members can hold each other accountable if some elements of it are not met.
The development team can include aspects not only to avoid Technical Debt but can also include aspects of how to tackle Technical Debt if it is accumulated during a Sprint.
Apply Usage Index- Stop Creating/Remove Features That No One wants
Product Owners, you can also help in preventing the new Technical Debt. Features that are not used by users/customers could be Technical Debt if they are not maintained at the same quality levels as the rest of the Product.
Recently, one of my teams came across a feature that is not used by any of our previous or existing customers. Worse was that there were no related automated tests. Not only it was causing difficulties in coding but also a good effort was getting wasted in manually regression testing it.
One of the ways to handle this is to use the value metric of the Usage Index.
Usage Index provides data that tell us which product features are not adding any value. It tells us which features are used most/least. It validates value assumptions.
Tip: Apply empiricism, gather the feature usage data, inspect it and adapt your product plan and strategy.
Product Owner should demonstrate the Scrum value of Courage by making a decision of removing the features that are not used.
There is no shame in it. Many successful companies do that. For example: Recently Samsung decided to stop supporting ‘S Voice’, once a rival of Apple’s Siri. ( source https://gizmodo.com/samsung-finally-says-bye-to-its-s-voice-assistant-1842825664).
A very good example of the Usage Index is given in the book Professional Scrum Product Owner by Don McGreal and Ralph Jocham.
Stop/Minimise ‘Quick & Dirty’ Fixes
How many times have you have seen a situation where Developers are asked to work on something ‘really urgent’. Developers generally rush of such emergencies and many times end up with compromising the quality. This lack of quality results in Technical Debt.
“The Dirty Stays, While Quick is long gone”. FromThe Professional Scrum Product Owner by Don McGreal and Ralph Jocham.
Product Owners can play a huge role in stopping/minimising these ‘Quick & Dirty’ fixes by doing a good rationalisation and showing courage to say ‘No’. Understand the impact of such fixes and ask powerful questions to understand whether these are really emergencies. They can also create an agreement that team will fix the Technical Debt sometimes in the near future otherwise they won’t do these quick & dirty fixes.
It could also happen if the Product Owner is more of an ‘order taker’ rather than the decision-maker. Empowering the Product Owner can help as well.
Tip: Scrum Master can also play huge in empowering Product Owner by taking the stance of ‘Change Agent’ and coaching organisation about the benefits of an empowered Product Owner.
Strategies to Tackle Existing Technical Debt
Sometimes Technical Debt is inevitable for example if an organisation’s survival is at stake if a feature is not delivered as soon as possible even if the quality of code is compromised.
In such cases, Scrum teams have to be practical and end up having Technical Debt. Sometimes Technical Debt is also because of historical poor quality standards or legacy codebase. This part we will discuss some techniques to tackle Technical Debt when it is already accumulated.
Make Technical Debt Transparent By Adding It To The Product Backlog
When Technical Debt is accumulated, it should be made transparent to people who are interested or affected by the product i.e. Scrum Team as well as stakeholders. This can be done by adding the Technical Debt to the Product Backlog.
Tip: If Technical Debt is quite high, make this an agenda item for each Sprint Review.
This allows the Scrum Team and stakeholders to have regular inspections of the Technical Debt its possible impact. Generally, Development Team members play a crucial role in identifying the cost of Technical Debt i.e. principal as well as interest.
Adding to the Product Backlog should also include capturing the negative value associated with Technical Debt. To make it more transparent for stakeholders it is advisable that this value is defined in business terms. These details will help the Product Owner to make better decisions about when is the right time to handle the Technical Debt.
For example, a Product Backlog Item can look like ‘Remove the duplicate modules and this will increase the performance of an online transaction by 2 sec providing better user satisfaction’.
Regularly Repay The Technical Debt- As Early As Possible
Ensure you have a plan to repay the Technical Debt. If you are not careful, the negative value associated with Technical Debt can be more than value-added by new features.
For example, if earned value because of the trade-off of quality over speed is £100,000. Now assume that this reduces a team’s productivity by 30% (including support) and there are 5 teams working on it. Each team’s daily cost is £2000.
Impact of Technical Debt for a month-long Sprint(20 working days)= £2000*5*20/100 = £20,000
With this calculation, within 5 Sprints, all the value earned would be lost because of interest paid by development teams. Hence, even to get the break-even, the technical debt must be fixed within 5 Sprints.
Return from Technical Debt must be greater than the impact of Technical Debt i.e. Principal + Interest Paid
It is important that the Scrum Team regularly checks the negative value related to Technical Debt so that it is not too late. Development Team should take the responsibility to make the cost highly visible to the Product Owner.
Tip: Visulising the technical Debt repayment can help bring transparency. Burndown Charts can be used for this purpose.
Measure The Technical Debt
I love the above quote from Peter Drucker. This applies to Technical Debt as well. If you are not measuring it, it would be difficult for you to get the buy-in from stakeholders.
Below are a few ways a Scrum Team can measure Technical Debt:
a) Release Stabilisation: This represents ‘how much time does it take to release software once the feature development stops’. This includes activities such as Regression Testing, bug fixes, fixing a number of crashes, etc. Many times this represents the outcomes of accumulating Technical Debt. For example, the lack of automated tests in a legacy code will end up doing manual regression testing that will increase the Release Stabilisation period.
b) Amount of Automation: Measuring Automation of Builds, Unit Tests, Regression Tests, Acceptance Tests, Deployment is a very good measure. Many times organisations fail to see the big picture and don’t invest money in the automation for the pursuit of feature delivery. They don’t see that in the long-run benefit of Automation are immense in terms of productivity, innovation, and product quality.
c) Cyclomatic Complexity: It is a very good measure to define the complexity of the codebase. Higher the Cyclomatic Complexity, more effort will be required to maintain the product.
d) The number of Bugs/Defects: More common metric than the above ones. The number of bugs in a product represents the quality of the product. This impacts not only development but also support & maintenance.
There are many other metrics as well that can be linked to Technical Debt such as Code Coverage, SQUALE-rating, etc. However, more important is not just measuring these metrics but look for trends and patterns.
Tip: Look for in which direction trends are going. For example, if the number of bugs is showing upwards trend than it is a danger sign and Scrum team should make some adaptations. Using ‘Radar Graphs’ or ‘Spider Charts’ is very good to visualise trends.
We learned in the article ‘The Hidden Cost Of Technical Debt’ what Technical Debt is and how it can cause pain to organisations.
This article we learned, how to tackle Technical Debt by not only just handling it when it is accumulated but also how to stop creating it as well.
In my experience, the above techniques have worked very well and I would really love to hear your experience as well. If you would like to share another technique then feel free to add in the comment box.
Till then stay agile and keep learning.