As a developer, my least favorite kind of work was being added to a project late in the game.
I felt like an archaeologist trying to clean up an artifact that's likely to crumble unless I worked very cautiously, analyzing each step. I complained that the software was poorly documented, when really no amount of documentation would have helped much, even if I trusted it. The act of *writing* the documentation can be a way to learn how it's supposed to work. Lately I've found writing *tests* provides more bang for buck.
The scariest part was never knowing for sure whether the last "fix" I made caused a regression failure.
The way to higher velocity and reduced risk in the long run is to incrementally add automated tests so you aren't flying blind as you make changes. You can't afford to add all the missing tests at once. Instead, you can prioritize where the test coverage is most needed, adding it incrementally as you also add business functionality.
Small amounts of technical debt can be repaid at the team's discretion, as a tax on each business work item accepted into a Sprint. The team and ScrumMaster may campaign for this with acceptance criteria such as:
- "Automated tests have been added to all existing code touched by the added code," or
- "We left it cleaner than we found it."
Large amounts of technical debt must be made visible as first class Product Backlog Items, to be split many times and prioritized along with the business stories. This approach will require the developers and ScrumMaster to explain each item's impact on development velocity in terms the business stakeholders can understand and prioritize appropriately. If they don't see why they should be concerned, refer them to Kane's article on technical debt, or call us for help.
Some parts of the legacy system may NEVER get test coverage, and that might be OK if those parts aren't involved in the changes and have been proven to work in the past, perhaps through years of manual testing and live deployment.
| Attachment | Size |
|---|---|
| TechnicalDebtSlides.pdf | 207.24 KB |
The idea that technical debt items appear as first-class Product Backlog Items contradicts the misconception that all PBIs (or stories) must have direct business value. At a recent Scrum Exchange I challenged participants to bring stories that could not be split into vertical slices. A participant we'll call "H" was very attached to the idea that none of his stories could be split small enough to complete in one Sprint because his system had fragile global tables inhibiting progress in any direction.
Other participants pointed out that this problem itself could be split. "H" was well versed in how he could do this, having read Michael Feathers' book Working Effectively With Legacy Code. But he couldn't imagine listing the technical debt itself on the Product Backlog.
The lesson for those of us who promote Scrum is to remind everyone:
Michael James
Software Process Consultant
http://www.danube.com