Technical debt is a burden on software innovation that we would rather avoid, and certainly clean up whenever possible. However, in most organizations, people don't prevent technical debt nearly as much as they should, and they rarely get the time to clean it up.

Why, then, if there are clear incentives to deal with technical debt, is it a rampant problem?

This session focuses on how to deal with technical debt on several levels, including the individual developer, the team, the software value stream, and the larger organization.

While technical debt may manifest itself in a developer's IDE, the problem starts long before the developer decides to copy and paste some code, or creates an overly-complex and under-documented class. The pressures on teams and individuals to take on more debt than they should come from many sources so the solutions to the technical debt problem must extend beyond the team.

As a result, this presentation takes an eclectic approach. Some of the highlights include the following:

  • An overview of technical debt. This section draws on various concepts from software economics to explain why a little bit isn't necessarily bad, but more than a little can be awful.
  • The triumph of short-term thinking. The Technical Debt Initiative created the Dice Of Debt game to demonstrate the importance of making long-term investments in reducing debt. This game is always a highly effective starting point for discussion of the reasons why people get stuck in the short-term thinking that increases debt.
  • The steps required to deal with technical debt, and the costs of both remediation and non-remediation. This section draws heavily on the work of the Technical Debt Initiative.
  • The distorting effect of technical debt on the team and the value stream. Cynefin and other theories of complexity are major elements in this part of the discussion. You may recognize the dysfunctions of your organization in this section.

The discussions of these topics include strategies that have worked for teams fighting technical debt.

For example, how can you use a simulation like Dice Of Debt, or the software economics of technical debt, to make a case to executives and middle managers that the investment in reducing debt is worth making?


Additional Resources

About the Speaker(s)

Declan Whelan, declan@leanintuit.com. Declan is an agile consultant, co-founder of Leanintuit and a director at the Agile Alliance. Declan works with organizations to improve their products and services through agile and lean practices. His personal mission is to change the conversation around technical debt. Rather than viewing is a technical problem to be fixed we need to view it as valuable feedback of the health of our organizations. We can use these health checks to improve our product and service delivery.

Tom Grant is an independent consultant (GameChange LLC) who help clients break through the barriers to successful software innovation. In his practice, he combines Agile, Lean, and serious games to change the rules of innovation when they're not working as well as they could. Tom has worked with a wide variety of clients, from Fortune 100 companies to start-ups, from IT to software companies.Some of Tom's areas of specialization include technical debt, Lean and Agile, management and leadership, Agile in highly regulated industries, requirements, tools, and frameworks. Tom's great passion is using serious games in Agile to get better customer insights, test strategies through simulated outcomes, adopt new practices and principles through experiential learning, and make smarter decisions.Tom is a contributor to the Agile Alliance's working group on technical debt. Previously, Tom has worked as practice director at Cutter Consortium, as a consultant at Net Objectives, and an analyst at Forrester Research. A native Californian, Tom now lives in Washington, DC.