Technical Debt Is a Systemic Problem, Not a Personal Failing

October 21, 2016 — Posted by Tom Grant
One of the underlying themes of the work we do at Net Objectives is, Agile by itself is not enough. Agile needs something that connects the transformation of the team to the activities and concerns of the larger organization. Nowhere is that more clear than technical debt. You need to nestle Agile within a larger operational approach, such as Lean, to deal effectively with a problem like technical debt.
One of the reasons why organizations accrue technical debt quickly is that they don't see it as a systemic problem. It's a problem with a component, the code, embedded within the larger system, the human and technological apparatus that builds and delivers software value. When brave and noble souls who want to clean up or prevent debt encounter resistance to the idea, they're usually arguing with someone who has taken only the very limited perspective of the code and the developers who create it.
Sure, technical debt makes it harder to write new code or fix the existing code. Yes, a debt-ridden code base can make the job horrible, reducing team morale, productivity, and commitment. Nonetheless, the person who doesn't want to invest in technical debt reduction or prevention thinks the price is worth getting to market faster, clearing out an impossibly large backlog, or just keeping the Corporate Masters happy with the perceived pace of work.

Technical Debt has Real Business Costs

The most immediate cost of technical debt, which you see when you run a static analysis of the code, trace the gradual increase in the average size of work items, is often not persuasive enough to get people to address it. The more frightening impact of technical debt happens at a larger system level,  something that you can't ascertain from measures like cyclomatic complexity or velocity. Here are a few examples:
  • Unreliable plans. The greater the technical debt, the harder it is to create reliable plans. Not only does technical debt make it harder to code than it should be, it also makes it harder to know how much extra effort will be needed. Gradually, estimates become less reliable – and so, too, do the plans based on those estimates.
  • Lost customer good will. Technical debt makes it harder to meet customer demands with new functionality. It also complicates efforts to fix issues, putting customer patience at risk.
  • Fewer portfolio options. Once technical debt reaches a certain level, organizations find it harder to manage projects or products at the portfolio level. A lower-value project might need more people to keep it on life support. The people who really understand the code, often because they created a lot of the technical debt in the first place, can't move on to other work. 
  • Lost market opportunities. When a new opportunity arises, such as expanding operations into new markets, the last thing executives want to hear is that some required code components are going to slow down that new endeavor.
  • Company valuation. One of the nasty surprises that software companies face is, yes, technical debt does affect your company valuation when someone wants to acquire you. Code quality can become a sticking point in an acquisition, for both small start-ups as well as established vendors.

The Business Is Often to Blame for Technical Debt

These are real costs that exist at a system level that you don't see by looking at the code. The system level is also where many of the root causes of technical debt reside. It's easy to blame the teams, or individuals on the teams, for their purported inexperience, unprofessionalism, or sloppiness. However, the real sources frequently lie elsewhere. Here are a few common culprits:
  • Hyper-demand. Many teams are working way over their capacity. The business' inability to prioritize, or make other hard decisions, means that software teams have to cut corners in order to keep pace with the demand for their work.
  • Short-term business thinking. The business often thinks in very short time horizons, driven by quarterly results and other concerns. That thinking leads to pressures on software teams to deliver something that achieves short-term results, without regard to long-term consequences.
  • Ignorance and distrust of how software professionals work. People outside of the development team generally don't understand how software development works, and they don't care. However, their ignorance has consequences, leading to statements like, "The prototype looks good – why don't we just ship it?" When the people making these statements don't trust software professionals, they will be deaf to their objections.

Technical Debt Is Often Beyond a Purely Agile Solution

Because the real causes and consequences of technical debt exist outside of the team, it's not surprising that Agile alone hasn't immunized teams against technical debt. To diagnose the problem, prescribe possible solutions, and assess their effectiveness, you need a broader, system-level perspective, which Lean provides. Flow, waste, value – these concepts are closer to the business causes and costs of technical debt than the Agile lexicon can describe.
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Tom Grant

Tom Grant is an analyst covering software development and delivery. His Specific focus areas include Agile, Lean, application lifecycle management (ALM), requirements, serious games, and the innovation process. Some of the serious games he has developed are teaching tools, often for people learning Agile software development practices. Others are simulations, intended to help people try out different innovation strategies. He has also taught political science at UC Irvine and Chapman College.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban