When time is short, even a well-disciplined team may cut a few corners. They might implement a code solution or automated tests in a less-than-optimal design, or make changes in old production or test code without taking time to refactor it. Future changes to this production or test code will be harder and take longer.
Ward Cunningham coined the term “technical debt” to represent the unfinished work due to shortcuts taken by the team to deliver a feature or user story faster. If we “borrowed” by skipping important steps, we have to pay back that “interest” quickly. If not, the interest will keep mounting up, and the growing technical debt burden will slow us down or even immobilize us.
Technical Debt Sprints
One way to pay down our technical debt is by devoting an entire iteration to activities such as refactoring production and test code to make it more maintainable and understandable, learning new ways of working better, upgrading test and code framework and tool versions, and improving the “living documentation” (also known as “automated tests”). We skip delivering new business value for just that iteration so we can pay down our technical debt.
“Sounds good,” you say, “but our product owner is never going to let us spend a whole iteration and not deliver new user stories to the business.” Or, you might be thinking, “Aren’t we supposed to ruthlessly refactor all the time? Why spend a whole sprint on refactoring?”
Even a highly disciplined team may run into limits to continual refactoring. If we have a lot of legacy code that is not supported with automated tests, it’s time-consuming to refactor and too risky if we don’t simultaneously add the tests. We also need to refactor our test code to keep tests maintainable and efficient. But, it can be risky to change our tests while code is changing.
There are other considerations. The team should choose its strategy. The work done in one quarter or a six-month period is going to be the same whether the team’s technical debt keeps growing—forcing them to work more slowly—or they devote some time exclusively to reducing the technical debt. Even with continuous refactoring, we find it works better to take some time to understand the debt and take the right steps to manage it for the long term. (See the sidebar for a helpful game about technical debt.)
Article continues below.
Technical Debt: Hard Choices
Nanda recently came across a game that explains technical debt and the results of not paying it back. The game, called Hard Choices, was designed by the Software Engineering Institute (SEI) and adapted from Shortcut: A Game About Speed and Risk by Elisabeth Hendrickson.
Basically, the game has the aspects of taking shortcuts (creating debt by incurring penalties) and paying it back (by losing a turn). If you don’t pay your debt, it will take you longer to reach the end.
Players can move in any direction and can even change directions in a single turn. They earn points by racking up “tool” cards and by being the first one to get to the end. For each bridge they cross, they must subtract one from subsequent rolls of the die.
Nanda plays differently than described in the SEI rules. In his version, three players still move the number of squares to match the roll of the die; however, there are specific rules for each player:
Nanda also changes the positions of the bridges so that each shortcut only bypasses a few squares, thereby making even clearer how Player 1 is going to suffer at the end. This is more like real life—shortcuts don’t usually buy you a huge amount of time. Played by these rules, Player 2 wins and Player 3 usually reaches the end ahead of Player 1.
The “Short Cut” game has similar rules, and several variations that let players experiment with different approaches to paying penalties back and changing goals from a competition to a collaborative team effort.
Playing either game helps teams and their managers understand the need for technical debt sprints to “keep the backyard clean.” At a minimum, this will allow the team to maintain its velocity, and there might even be a big improvement.