I got positive feedback on this post to the agile-testing Yahoogroup (including from Brian Marick), so I decided to post it here too for anyone who missed it on the list.
My team took time to educate the business management about technical debt and how it affects our velocity. They can see our velocity start to go down if we accumulate too much technical debt. This means fewer new features. We’ve tried to translate technical debt into things they can understand – dollars and cents, less ability to deliver features in a timely manner.
Our agreement with the business is that we get one two-week iteration every 6 months for ourselves, to do big refactorings (we always refactor, but sometimes it’s risky to do in a regular iteration), to upgrade our tools, to try out new tools. For example, we switched from CVS to SVN during a “refactoring” sprint. If a major refactoring is needed in the production code, we do it early in the “refactoring” iteration so we have lots of time to test it.
Over the years the business has seen the benefits of our “refactoring” sprints. They see the velocity go back up and how the investment of a small amount of time pays off.
People say, “My business will never let us do that”. You have to build trust between the software team and the business team. My team puts a lot of effort into understanding the business. We sit with different people and watch how they work. We document business processes and suggest ways we could help with software. We can help the business by suggesting a lower-cost or higher-ROI solution to a business problem. We know enough about the business to help set priorities. When a new theme is coming up, we can identify dependencies and help find the most efficient way to develop the theme. We identify “bling” and help keep the business looking at ROI. We’re all invested in a successful business, after all.
We’re currently overdue for a “refactoring” sprint, so we’ve had to start writing stories and budgeting extra time for activities to reduce our technical debt in each sprint. The business people know they are getting lower velocity, it’s their choice to put off the refactoring sprint and they know they’re paying a price for it.
Your team needs to find what works for you, but try to open a dialog with the business managers, try to understand them and help them understand what technical debt is and how it hurts the business bottom line.
One comment on “Managing Technical Debt”
Hello Lisa,
I like the idea of a “refactoring” iteration, and applied it whenever possible.
I found a complicating factor being project teams owning a portfolio of several projects, and doing the following:
1.) alternating work on those projects with a significant gap of time, and/or
2.) changing developers working on the code
Given that embarking in a refactoring requires knowledge of the system,
the above issues frustrate attempts for doing it seriously: you either loose knowledge of the system by prolongued lack of attention, or by task switching.
It would be interesting to see how similar project teams cope with this problem.