The Specter of Technical Debt Looms

The specter of technical debt looms over all projects. Too much technical debt will kill your momentum, but most technical debt is invisible to users. One of the core tenants of building software using agile methodologies is constantly delivering value to the users. This presents a conundrum. How do you pay off technical debt, which is usually invisible, while also delivering useful features? To answer this important question, I reached out to some of my fellow Centarans and asked them the following:

What is the best way to include tech debt and maintenance in your value stream? ie. How do you integrate user invisible work when you're using agile processes?

Sienna Bast

<codeblocktest></codeblocktest>

While developers always try to write code with future limitations in mind, tech debt is an almost inevitable challenge on any large-scale software project. With deadlines and exciting new features being released quickly, tech debt items can often times be forgotten or deprioritized.

An important skill to remember is to explain why tech debt needs to be prioritized with the overall product in mind. Sure,something may be really bugging you as a developer, but what will happen on a product level if this bad practice continues in the application? Perhaps future development will take twice the amount of time or blocking bugs could potentially pop up since the system is so fragile. Showing the product team and stakeholders how tech debt will affect THEM is an effective way to get everyone thinking on the same page. With a shared mindset, the entire team can work together to place tech debt at the appropriate priority.

<codeblocktest></codeblocktest>

David Pine

<codeblocktest></codeblocktest>

“Performance is a feature” – Jeff Atwood.

With that said I think of tech debt differently than I do maintenance. As it pertains to the value stream maintenance, it's mandatory, whereas tech debt is accrued by design implications. One does not simply disbar tech debt, one must analyze it and decide if the investment is valuable enough to justify. Thus adding to the value stream, performance is one example of this.

<codeblocktest></codeblocktest>

Tyler Evert

<codeblocktest></codeblocktest>

Since tech debt is a value-added exercise for your company and not the customer, we want to keep it to a minimum while continuing to deliver customer value for feedback. We also don't want large amounts of tech debt disrupting our progress through customer-valuable work, since that makes it difficult to create reliable long-term forecasts.

The best way to handle tech debt and maintenance is the same way we handle all other internal, non-value-add activities (testing, deployment, etc) – do it in little bits, continuously, as you go. This involves a lot of engineering skill to be able to segment things out into manageable chunks, but the rewards are great. Additionally, I would advise not assigning story point value to anything that doesn't directly provide customer-value. This causes your velocity to go down as a result of spending time on tech debt, which gives you more accurate long-term projections and reasonable expectations. It can also be a good focal point for discussion with stakeholders – e.g. “because of that time you made us rush a release out, we now have to spend extra time cleaning it up, and that makes us slower”.

<codeblocktest></codeblocktest>

Graham Mueller

<codeblocktest></codeblocktest>

There's always a balance between getting stuff done™ and going back to clean up areas that didn't work out the way you would have hoped the first time you write it. This is an even more difficult balance when you're being paid hourly, and the client doesn't see why they should pay more to have you “fix” what's already working as far as they can see. We're not a sprinting team, we use Kanban, so we have a slightly different setup. In a sprinting team, you can sometimes find a bit of time to try to tackle some of these sorts of things if you hit your sprint goals, or you can plan some time into a sprint for them. In a Kanban setup, you're supposed to pull the next highest priority once you've finished the last task. The trick of that is to find a way to make tech debt your highest priority, which we typically do by showing how it impacts other stories we want to work on. Maybe it makes it impossible to tackle another story, or at least significantly impacts the amount of time it will take. We also try to tackle some smaller bits of tech debt in as we're working our way through code we haven't touched in a while, trying to leave the code in better shape than when we approached it.

<codeblocktest></codeblocktest>

Duane Raiche

<codeblocktest></codeblocktest>

In a perfect world, the business and development team would always be in sync about code maintenance priority vs new work priority and it could be placed into your backlog like any other work. In lieu of that, I have found that the best way to include tech debt and maintenance in your value stream is to make it a habit to always build in a small amount of time into your sprints for it as part of sprint planning. This does require some business buy-in, but you can keep it time-boxed so no single sprint suffers too much, and you can make the case that maintaining high quality code speeds up future work. Each sprint you get a portion of time to help keep your code in tip-top shape, and the priority of this can usually be left up to the development team themselves to do what they think is the most important.

<codeblocktest></codeblocktest>

Jeff Bubolz

<codeblocktest></codeblocktest>

Technical debt is not like low interest equity debt on your house, it is like high interest credit card debt. This is something that should be discussed with stakeholders and the scrum team to find an aggressive plan to attack it. Having a technical debt sprint is not a good idea. Teams should be delivering business value every sprint. I recommend the boy scout rule: leave the area you are working on in a better state than you found it. As you touch an area that has technical debt, you fix that technical debt. I often get push back from stakeholders about working on technical debt. The argument that I make to them is that we need to slow down to go faster in the future. We want to optimize for our product's long-term success.

<codeblocktest></codeblocktest>

How do you balance these two important concerns?

Get your project started today

Get in Touch