Want to have some fun? Gather several of your technology colleagues or outside collaborators and ask them to share their favorite technical debt horror stories. You’ll hear about bad code, legacy platforms, and repetitive outages — and you’ll quickly realize that you’re not alone in the uphill battle to avoid and reduce tech debt.

I tell many of my tech debt horror stories in my upcoming book, Digital Trailblazer: Essential Lessons to Jumpstart Transformation and Accelerate Your Technology Leadership. And I’m not shy in sharing some of the technical debts that I had a hand in creating.

Now griping and venting about tech debt can be fun, but it’s a temporary stress reliever and can be detrimental when other people are blamed for the predicaments. Be the Digital Trailblazer that offers solutions to top tech debt issues and develops standards that minimize introducing new tech debts.

Here are my recommendations on how to avoid bogging down your DevOps teams and IT organizations with technical debt.

1. Increase time for agile planning and documenting solutions

You don’t see pro football teams figuring out new plays in the huddle during a game. There’s a playbook that’s developed and continuously improved – based on team strengths, past performances, their opponent’s weaknesses, and the game circumstances.

There’s an analogy with agile development teams that develop solutions for user stories at the start of the sprint or have shallow backlogs with no planning for future releases. I wrote about this and other forms of just-in-time planning and solving them with agile continuous planning in last week’s post.

Teams that aren’t planning their solutions, allowing time to iteratively improve them, and documenting their architectures are more likely to create technical debt – and they are certainly less likely to recognize opportunities to reduce existing debt.

2. Institute disciplines to challenge assumptions and review existing solutions

Trust me, I get it. I was a developer once and loved coding elegant solutions. And I disliked reading other people’s often-crappy code, especially if I had no choice and had to perform refactoring with surgical precision.

But times have changed! DevOps teams have cloud services, open-source libraries, freely available coding examples, low-code / no-code options, and in-house microservices to leverage when reviewing requirements and considering solutions. The last thing you want is teams to jump into mob programming without considering how to best leverage existing solutions.

That requires delivery managers and agile team leads to instill discipline when brainstorming solutions. Developing too much code increases the likelihood of creating new technical debt. Reusing and reapplying existing vetted code – that not only reduces debt it also reduces the amount of code DevOps teams need to support.

3. Define your devops non-negotiable policies on reducing technical debt

When you define a policy as non-negotiable, it becomes a cornerstone of agile operating principles. DevOps teams either get it, or they come to the table with challenges and requests for exceptions.

What are some non-negotiables to consider?

• What percent of an agile team’s work, measured over 3-6 months, should be dedicated to reducing technical debt? I share my recommendations in one of my classic posts on how to get an agile product owner to pay for technical debt.
• What development, testing, and other DevOps tech debt avoidance practices are you standardizing on? See recommendations in the article on how to minimize new technical debt.
• When is it ok and reasonable to introduce new technical debt, and what should agile teams do to document and manage the tech debt backlog? Equally important – when is it not ok? One good post separates the notion of debt versus bad code, and others dimensionalize tech debt between reckless vs. prudent and deliberate versus inadvertent.
• What steps should agile teams take to manage existing technical debt? I share five ways to better manage technical debt in a previous post.
• What are your principles around continuous testing? DevOps teams that seek to increase deployment frequency can easily create inadvertent technical debt when pushing the development gas pedal past the speed limit. In a previous post, I asked developers to slow down and stop deploying buggy software, and instrumenting continuous testing is one way to put the guardrails up to prevent bugs and avoidable technical debt.

So go ahead, vet, share stories, and learn about how your colleagues manage technical debt. Then, become a Digital Trailblazer and lead the way for DevOps teams to manage it.