Introduction
Looking from IT and technical perspective, one of the things that hinder the progress and effectiveness significantly of Scrum Teams is technical debt.
Technical debt affects overall product quality and health, delivery forecasts and costs of the execution. If and when left unpaid, it creates something that most teams are not even aware of in background of their work.
Let’s dive deeper and understand what is technical debt and how it affects overall effectivenss and value delivery of Scrum Team.
What is Technical Debt Exactly?
Technical debt refers to the implied cost of additional work (rework) that arises when Developers choose an easier or quicker solution over a more effective, long-term approach.
I like to say – prioritization of speed over quality.
Sometimes it is necessary to meet forecasts of the project, product, building a tool or something more abstract. Unchecked technical debt can lead to more complex codebases, poor maintainability of the code and reduced performance of the software, tool and product.
Technical debt is like financial debt, you must pay it sooner or later. The more you wait, the more it accumulates and turns your system to be more complex. For example: previously you needed 2-hours to do specific piece of work, with technical debt it will increased to 4-hours or even more (depends on the complexity of work).
How Technical Debt Impacts Scrum Teams?
- Reduced effectiveness of the Scrum Team: Allocating more time addressing bug (errors) and code fixes (refactoring) than developing new, more innovative functionalities
- Decreased product quality (health): Product becomes harder to maintain and extend, impacting user experience and satisfaction
- Lower Scrum Team morale: Constant firefighting without building something innovative and creative lead to Developer burnout and frustration
- Higher long-term costs: Quick fixes may save time initially but ofter lead to greater expenses in the long-run due to increased rework/undone work
How and When to Identify Technical Debt in Scrum Teams?
Most important step when it comes to technical debt is to make it transparent. When areas of technical debt are visible and wellunderstood, than it’s time to manage it effectively.
1. Code Reviews
- Frequent and diligent code reviewes to identify and make transparent potential issues early in coding activities
- As a Scrum Team identify and agree upon tools that analyze code complexity and potential technical debt (SonarQube, Code Climate, etc.)
- Make code rewievs a collaborative activity, this can be done by running pair-programming activities, where one developer is Driver and another Navigator
2. Sprint Retrospectives
- Sprint Retrospectives are great time and place to discuss as a Scrum Team how to make technical debt transparent and manage it effectively throughout the Sprint(s)
- Strengthening the Definition of Done by adding quality standards that will include paying back some technical debt is also a good way forward
3. Automated Testing and CI/CD
- Implementation of CI/CD activities and practices in order to identify code defects early in development process is something that will save a lot of time for Developers
- Utilization of tools for CI/CD such as Jenkins, Travis CI, GitHub can streamline and help with identification of poor written code
4. Product Backlog
- Product Backlog artfiact in Scrum should consists of Product Backlog Items needed to build/improve product, tool or something more abstract. This can also include technical debt work items
- Categorize technical debt Product Backlog Items based on impact, severity and the effort needed to resolve them
- Create balance between new features and technical debt payment and align it with Product Goal.
Anecdote from my previous experience
I was part of one Scrum Team where we throughout every Sprint had at least 2 work items related to technical debt. That enabled us to – in one hand build something creative and innovative and also pay some technical debt every Sprint. After couple of Sprints (4-6) this puts us in a really good spot at that time.
Conclusion
Technical debt is inevitable in software development, but managing it effectively can prevent it from becoming a big bottleneck.
By developing technical debt management skills in a Scrum Team, team members can maintain product quality on a high-level, improve forecasts, optimize predictability and reduce complexity of the work throughout the Sprint.
How does your Scrum Team currently handle technical debt?
Share your experiences or strategies in the comments below!
