Letting Debt Build Up

Here’s something that Todd has witnessed many times as a developer on Scrum teams:

A Scrum team sits in sprint planning debating how they’re going to implement a product backlog item. It isn’t an easy conversation because this particular item touches a very fragile part of the application. The Scrum team has known this for some time, yet nothing has been done to change it.

The product owner really wants this item to be done because she’d been hearing a lot of demand for it from customers. The development team doesn’t feel confident that they can accomplish this item without breaking something that’s already in production. They forecast that refactoring the relevant part of the code base could take multiple sprints. This is a conversation that has happened many times between the product owner and the development team. In the past, the development team has always heroically built upon the fragile code, increasing its fragility but delivering the feature.

But this time is different. The last time they added functionality in this area, a bug brought the product to a screeching halt in production, causing a sprint cancellation to cope with and fix the issues. They managed to cobble things together but they lost the trust of their stakeholders—and the team was scarred from it. The Scrum team is now in a pickle because they don’t want to repeat that same production-halting mistake.

What if this team could go back in time to a sprint planning session where this issue was first discussed? Imagine if, rather than bolting new features onto the fragile code base, they decided to take the few days they forecasted at that time to refactor while delivering the new functionality.

Fragile code bases plague the software development community. There’s no way to quantify technical debt nor to imagine life without it during planning, unless it’s allowed to be fixed by the development team.

Conversations during sprint planning should include the “how”: How are we as a development team going to implement this product backlog item? If there are signs that things are getting tough in a particular aspect of a code base, ask these questions during sprint planning:

• Is there are way that we could make that area friendlier to code in?

• Are there any automated tests that would cover the existing functionality?

• Is it worth working together in pairs to find a way to make the code more robust?

• What can we do to make this code less fragile?

Rather than ending up with a product backlog that has a bunch of “refactor” items, take on technical debt immediately when it enters the conversation. If there is technical debt, incorporate resolving it into a product backlog item that delivers some sort of business value. Don’t ignore it or you may end up drowning in debt.

Remember that the development team owns how to accomplish the work: They decide what needs to be done technically, the scope of the work, and what goes into the sprint backlog. If the dev team takes a stand against shortcuts and technical debt, nobody can force them to do bad work. If more teams took this approach, the world wouldn’t have so many technical messes to contend with. Professional Scrum teams embrace technical excellence.