Don’t Firefight, Just Manage It!!

As an Agilist, I am dedicated to applying innovative, collaborative, and enjoyable methods to achieve goals for individuals and teams. However, a recurring challenge, faced not only by me but by many teams and projects, revolves around a common question: 'How to handle Technical Debt?'

In recent interactions, I've observed that numerous agile practitioners face the dilemma that organizations lack a uniform process or best practice for managing technical debt. It's not uncommon for ad hoc tasks to be prioritized over planned work during a sprint, leading to a cascade of issues such as more spillovers and an ongoing cycle of firefighting.

The absence of a standardized approach to technical debt management can hinder the overall agility and efficiency of teams. To address this challenge, it is imperative to establish a comprehensive and consistent strategy for handling technical debt throughout the software development lifecycle.

There is a famous phrase: 'If you can measure it, you can manage it.' This applies to Technical Debt as well. Ask yourself, 'What is the size of the technical debt in my project?' If you know the answer, you can certainly move in the right direction with it.

If you don't know the size of technical debt, then as a team, you should collaborate and identify ways to measure it. One of the best practices my team followed, with the help of tools like Jira, is to add a custom field, such as 'story type,' in the Issue type 'Story.'

Here are some examples of Story Types:

• New Functionality: New Feature Development
• Tech Debt: Technical Debt
• Retrospective: Action Items from the retrospective created as a story
• Documentation: Mandatory documentation work needed to be done by teams.
• Security: Application Security-related work needed to be done by the team.

Feel free to find and create more suitable story types according to your needs.

Now, User Stories, whether already existing or to be created for the future, can be categorized by 'Story Type.' With standard estimation techniques already in place, we can now measure the size of technical debt in our project.

So far, we have reached only the halfway stage…

The next step is to Define Clear Policies: Establish clear and well-defined policies for prioritizing and addressing technical debt. Ensure that the entire team understands and follows these policies consistently.

One effective policy that a team can implement is the Rule of 60:20:20:

• 60% for Planned Work: This includes new features and functionalities aligned with the sprint goal.
• 20% for Unplanned Work: Reserved for urgent bug fixes or unexpected issues.
• 20% for Continuous Improvement: Dedicated to addressing technical debt or making process improvements.

By applying this rule, the team should plan the sprints. This balanced approach ensures that the team focuses on planned tasks while also being prepared to handle unforeseen challenges and actively engage in continuous improvement efforts.

Regards,

Nagesh Deshpande

Senior Scrum Master

ICP-ACC | ICP-ATF | SAFe Agilist 6.0 | PSM II | KMP I?|?LEAN?|?ISTQB