Prioritizing Tech Debt in Your Agile Planning Process

“Product people will always choose new features over improving infrastructure during the Agile planning process.”

Many frustrated Agile development teams frequently express this sentiment. As a product person myself, I cringe when team members say something to this effect, but these concerns come from real experiences engineers face every day.

I took on my first product management role in 2010, and in the time since, I have learned some practical techniques about how engineers and product people can incorporate tech debt conversations into the Agile process that are more fruitful than frustrating. Whether you are an engineer who does not want the stress of building new things on a house-of-cards infrastructure or a product person who is not quite sure how to balance prioritizing features with tech debt work (or why) during the Agile planning process, this article will give you some things to think about and try.

What Even is Tech Debt?

Thinking of tech debt in similar terms to financial debt can be a grounding way to frame your mindset about it. Instead of owing money, you owe work to maintain and build on your codebase in the future.

It’s work you choose not to do now to get something done quicker and easier, to achieve the goals you set during your Agile planning ceremonies. Choices like leveraging a third-party library that requires a lot of supporting code for your infrastructure and writing less DRY, less modular, less standardized, and less automated code each have potential debt considerations.

The equivalent of financial interest in the tech debt world is that your code will be more complicated and/or risky to update until that refactor work is done to simplify/derisk maintaining it. So signing yourself up to do refactor work in the future is the debt, and working to maintain and build on your code until you refactor is the interest.

Why Take on Tech Debt in the First Place?

Like financial debt, tech debt is not an innately bad thing. Like a mortgage that lets you buy a house now, it can allow you the opportunity to accomplish an important goal sooner than you otherwise might be able to.

Getting a feature out the door to meet the commitments you agreed to during your Agile planning ceremony, such as finding out if it has the impacts you anticipate, solving an urgent issue, or making money from it sooner are all legitimate justifications for taking on tech debt. The pitfalls come when your organization takes on debt without an explicit understanding of how you will manage it and ultimately pay it off.

Engineers need to be upfront about the debt they can suggest as an option, and product people need to be willing to commit to a reasonable plan for paying off debt if they choose to take it on. Having strategic conversations about what that looks like can help frame key elements of your product’s growth strategy. If a team can trust that they will be afforded the time needed to pay off their tech debt and that it will be incorporated into the Agile planning process, then they may be more open to suggesting options to accomplish the goal even if it means accumulating tech debt.

The Before Conversation

Many Agile development teams take on tech debt without an explicit understanding of how the decision fits into the organization’s Agile process or how it impacts the rest of the organization in the long run. Maybe they feel pressured to complete something as quickly as possible because of the commitments made during an Agile planning ceremony, regardless of technical consequences. Maybe they expect they’ll be allowed to circle back and clean things up after the pressure of a deadline has passed. Whatever the reasons may be, you can alleviate putting your Agile development team in this predicament by having a dialogue with your stakeholders that puts the impacts of taking on debt (or not) in terms that matter most to your audience.

Terms That Matter Most to Your Audience

As product people are often called upon to do, the CEO of my company asked me to determine when we could deliver something. After facilitating conversations with the three Agile development teams involved to break down the features, talk estimates, and implementation tactic scenarios, I did some analysis and presented her with a range of possible delivery times. By the way, this can be done effectively using an Agile management tool such as Rally.

She pointed to my slide and asked “Why am I looking at such a wide time range? I mean as CEO if you tell me I can have this in February, why would I say it’s ok to take until April?” It’s a great question.

I explained we can take longer upfront to write this more cleanly from the start, and this would put us on track for an April delivery. However, if we want it in the hands of users faster, then we can implement it faster in such a way that would mean incurring tech debt.

We would need to invest effort post-release in paying off that tech debt or else be stuck incurring interest on that debt that would make it take even longer to pay off down the line. This is not about quality, mind you. The intention is not to release bug-infested code but to hold back investment in automation, standardization, and other infrastructure that makes the code more maintainable long term.

The decisions that impact where we fall in that February to April timeframe include things like:

• How confident are we that what we are building isn’t going to change dramatically once customers see it? A high confidence level in limited changes warrants the upfront investment in cleaner code.
• Is it valuable enough for customers to see it in February instead of April knowing we’ll have several weeks' worth of tech debt to pay off?
• What other projects will be impacted in the following months to pay off any tech debt incurred due to this project?

This exchange put the decision to incur tech debt or not in terms that mattered most to my CEO.

Interested in learning more? Read my second post in this series to learn how to make the case to pay down tech debt to your leadership team.

Visit Broadcom's Enterprise Software Academy to up-level your agile skills and knowledge about Rally software.