Tackling Technical Debt
Software development is an organic process wherein the software evolves, it changes hands with multiple developers, it weathers continuously changing customer requirements and technologies every day. All this chaos is orchestrated around a forever looming delivery deadline which can never be far enough. Invariably the software developer ventures on a road that comes with a price, thus incurring Technical Debt.
The subtlety of Technical Debt is that it rarely can be seen by the end-user or the stakeholders as it doesn’t always affect the business logic or pops up in their day-to-day product usage. It lurks underneath the User Interface like a ticking bomb, waiting for the next Change Request or next New Feature Requirement for it to reveal itself. And when it hits you it brings chaos! It affects the customer in monetary terms due to the Cost of Delay of the feature; and it costs the developers with a longer time to complete their tasks.
But enough gloom! There is light at the end of this tunnel. An important step here is to acknowledge that there is a problem and then it can be mitigated.
“The Product Owner wants to build the right product and the developer want to build the product right.” [2]
Both are noble pursuits but many times leads to different paths.
A balancing act is required here to match customer expectations with product quality. Thus it is paramount for developers to identify the presence of technical debt and work with the Product Owner to prioritize it in your sprint planning. It cannot be done in one shot it has to be done in an incremental fashion.
Technical Debt was identified as the number one problem in one of our team retrospectives. We had a long brainstorming session to find a mitigation strategy for the same. The first thing we noticed that we all knew there is a problem but we didn’t have a clue about the size, scale, and complexity of the task at hand. So we followed these 3 steps to help mitigate this issue:
Step 1: Quantify:
You know you have a problem so let’s size it up. It is imperative to size the tasks identified if we do not know the scale of the problem we are dealing with, it's not possible to form a befitting strategy to handle it. Also, identify the severity and the priority of the tasks in hand with techniques like MoScoW Analyses. So at the end of this step, we should:
Create a Technical Debt Epic
Identify target Technical Debt Tasks/Stories
Size them up
Assign Priority/Severity
We are using Atlassian Jira, so my example has very Jira specific terms. But basically we need to identify these Technical Debt user stories, add them to the product backlog and bundle them together with something like Epic so as to track progress in the future. Epics, Stories, and Tasks are terms that you won’t find in the Scrum Guide, but many teams use them to discuss Product Backlog Items.
Step 2: Plan
During the Sprint Planning, decide with the team to take up a few of the Technical Debt tasks that have been prioritized already in the previous step. It would be a good idea to align with the Product Owner about some fixed bandwidth per sprint to work on this activity e.g. 10–20% of our story points each sprint can come strictly from Technical Debt epic. There is no “Golden Ratio” here for feature development, maintenance/bug fixing, or technical debt, do few inspect & adapt cycles to find the right balance for your team.
Step 3: Visualize
When the Development Team is putting in the time and the effort, Sprint after Sprint to work on Technical Debt, they should be able to view the progress done and see how far they have come. If you are using Jira utilize the Epic burn-down chart for the Technical debt epic and show the team how much progress is done so far. This is a crucial step as it shows the fruits of their labor and motivates the team to continue on that road.
Ideally, keep repeating these three steps every sprint and step-by-step climb the mountain of Technical Debt. Keep a check on the changing requirements of the product and keep refining the priority of the tasks. By following these three steps slowly and steadily every team should be on its way to get rid of Technical Debt.
References:
[1] Scrum.org — https://www.scrum.org/
[2] The 8 Stances of a Scrum Master — Barry Overeem — https://www.barryovereem.com/wp-content/uploads/The-8-Stances-of-a-Scrum-Master-Whitepaper-v2.pdf
