Managing Technical Debt in Agile Environments

While developing products in DevOps teams, we make decisions on which features to develop and how to ship them quite quickly in order to meet customer requirements. Often, these decisions cause more problems in the long run. These kinds of decisions lead to “Technical Debt”.

Tech debt is a phenomenon that happens when we prioritize the speed of delivery now, by forgoing everything like code quality or maintainability. Although the agility of delivering products is key to staying relevant in this agile world, we also have to make decisions that ensure the changes are sustainable.

In this article, we'll talk about what technical debt is, how to handle quick decisions during development, and give examples to help you understand how to avoid future issues.

Tech debt is the extra work that has to be done later because of the technical decisions that we make now. Although it was coined by software developer Ward Cunningham in 1992, it still holds relevance.

Usually, Technical debt occurs when teams rush to push new features within deadlines, by writing code without thinking about other considerations such as security, extensibility, etc. Over time, the tech debt increases and becomes difficult to manage. The only way to deal with it then becomes to overhaul the entire system and rewrite everything from scratch. To prevent this scenario, we need to continuously groom the tech debt, and to do that, we need to understand the type of tech debt we are dealing with.

Causes of Tech Debt

• Prudent and deliberate: Prioritizing swift shipping while postponing dealing with their consequences is deliberate debt. This can be taken up when the product is still in the MVP phase or the benefits of quick delivery outweigh potential risks.

  
  

• Reckless and deliberate: Despite knowing how to craft better code, prioritizing rapid delivery over quality leads to reckless and deliberate debt.

  
  

• Prudent and inadvertent: Prudent and inadvertent debt occurs when there's a commitment to producing high-quality code, but this solution was discovered after the feature has been shipped.

  
  

• Reckless and inadvertent: Reckless and inadvertent debt arises when the team tries to implement coding best practices without actually understanding how or why to implement them. This often leads the teams to making a different kind of tech debt.

Given these different causes for tech debts, let's try to understand the types of tech debts. These can be broadly categorized under three main heads:

Code Related Debts:

• Code Debt: When we talk about tech debt, code debt is the first thing that comes to mind. It is due to bad coding practices, not following proper coding standards, insufficient code documentation, etc. This type of debt causes problems in terms of maintainability, extensibility, security, etc.

  
  

• Testing Debt: This occurs when the entire testing strategy is inadequate, which includes the absence of unit tests, integration tests, and adequate test coverage. This kind of debt causes us to lose confidence in pushing new code changes and increases the risk of defects and bugs surfacing in production, potentially leading to system failures and customer dissatisfaction.

  
  

• Documentation Debt: This manifests when documentation is either insufficient or outdated. It poses challenges for both new and existing team members in comprehending the system and the rationale behind certain decisions, thereby impeding efficiency in maintenance and development efforts.

Architecture Debt:

• Design Debt: This emerges from flawed or outdated software architecture or design choices. It encompasses overly intricate designs, improper utilization of patterns, and a lack of modularity. Design debt presents obstacles to scalability and the seamless incorporation of new features.

  
  

• Infrastructure Debt: This is linked to the operational environment of the software, encompassing issues such as outdated servers, inadequate deployment practices, or the absence of comprehensive disaster recovery plans. Infrastructure debt can result in performance bottlenecks and increased periods of downtime.

  
  

• Dependency Debt: This arises from reliance on outdated or unsupported third-party libraries, frameworks, or tools. Such dependency exposes the software to potential security vulnerabilities and integration complexities.

People/Management Debt:

• Process Debt: This pertains to inefficient or outdated development processes and methodologies. It encompasses poor communication practices, a deficiency in agile methodologies adoption, and a lack of robust collaboration tools. In addition to this, there is the issue of not automating the process, which greatly increases the agility of software delivery.

  
  

• People/Technical Skills Debt: This is when the team lacks essential skills or knowledge, resulting in the implementation of suboptimal solutions. Investment in training and development initiatives can serve to mitigate this form of debt.

Managing and Prioritising the tech debt

Technical debt is something that happens when teams are developing products in an agile way. It's like borrowing against the future by taking shortcuts now. But if the team knows about this debt and has a plan to deal with it later, it can actually help prioritize tasks. Whether the debt was intentional or not, it is crucial that the team grooms the technical debt during a backlog refinement session.

Here's how you can categorize these tasks:

1. Do It Right Away: These are tasks that are crucial for keeping the product running smoothly.
2. A Worthy Investment: These tasks contribute to the long-term health of the product, like upgrading outdated systems.
3. Quick and Easy Wins: These are small tasks that can be fixed easily. They're great for new team members to learn about the product.
4. Not Worth Considering: Sometimes, the problem might solve itself or it might not be worth the time and effort to fix, especially if you're planning to upgrade or retire a system.

When building a new product/feature or facing tight deadlines, it quite common to choose speed delivery over the quality or code sustainability in the long run. Striking balance between the need for quick solutions while maintaining the long term vision for sustainable development practices is the key. Managing technical debt effectively can help ensure the success of your projects in the long term.

Like my content? Feel free to reach out to my LinkedIn for interesting content and productive discussions.