The most common question I receive is on the issue of handling technical debt in Agile. Specifically, team leaders want to know how to pay down technical debt while still providing business value. It appears difficult because the goal of Agile is to consistently provide business value. This is often interpreted as delivering fast and dirty. However, Agile has an explicit goal of providing long-term value through great software and happy customers. Technical debt is a long-term cancer on product viability and customer satisfaction.
Paying down technical debt is not easy. It requires patience and perseverance to make changes to working software with out introducing regressions. That being said, the common question needs to be answered: “How do I get approval from the business to pay down technical debt?”
You don’t.
As a professional software developer, you don’t need permission to do your job well. This includes writing unit tests, testing your software, logging, fault-tolerant architecture, and paying down technical debt. Do some tough soul searching and ask yourself why you feel it’s necessary to ask permission to do your job well. Many who are asking for permission are looking for a reason to blame someone else for failure. It’s usually a combination of laziness, lack of skill, or fear of introducing regressions. I can’t help with laziness, but I can help with the other two.
The real problem is controlling the amount of change as to minimize the impact on business deliverables and prevent regressive defects. This is done in two ways:
Point Allotment
Every iteration should allot 10% of story points to improving software. This could be adding automated testing, CI, architecture refactoring. It’s critical to understand, these stories are just like any other stories. They’re defined stories with requirements, code review, and acceptance criteria. By working in small stories, each iteration, the software will pay down it’s technical debt over time.
Of course, if you don’t estimate stories by points, you’ll have a hard time adopting this policy. You need a more mature Agile process. Call me.
Require Unit Testing
Unit testing will always improve your software. It forces the team to selectively refactor old code and ensure modified code is resilient to regression. This requires you have a CI system in place and measure coverage. Without coverage and CI, it’s difficult to monitor the effectiveness of unit tests.
- Everything is a P1 - July 22, 2020
- The Danger of Agenda-less Meetings - April 21, 2020
- Strictly Agile - February 12, 2018