These are exciting times in the IT industry. The cloud, DevOps, the Internet of Things, machine learning, and countless other innovations are rapidly changing our marketplace.
While this is exciting, you may find it challenging to rise to these market opportunities. New technologies offer a myriad of choices often with steep learning curves. Maintaining existing systems and rolling out releases at market cadence places demands on internal technical capacity. The friction in rolling out new features is called Technical Debt. Without prudent management, this debt will grow and severely impact your ability to deliver value.
The Agile Alliance Technical Debt Initiative has put together a four-step approach, based on the OODA Loop, to help you manage technical debt.
Observe
The first step is to identify and measure the technical debt in your products. This could be as simple as asking developers to measure how much they are slowed by technical debt in certain products or parts of the code. Or you could use tools to automatically measure technical debt as part of your build process.
Orient
While raw technical debt measures are important, it is even more important to put them into a wider context by characterizing the impact of the technical debt. For example, technical debt in a product undergoing a lot of change is less important than technical debt in stable products that rarely change. You may also want to orient your teams to the technical debt concept. We have developed the Dice of Debt game which is a fun and informative way to explore the impact of technical debt.
Decide
Now that you have measured and oriented your teams to technical debt you could schedule technical debt iterations or add technical debt stories to your product backlog. See project management and technical debt for additional insights and approaches to dealing with technical debt.
Act
Let’s do this! The simplest, and most effective, technique for dealing with technical debt is to apply the “Boy Scout” rule and have teams commit to keeping the code clean through opportunistic refactoring. Teams could include technical debt reduction as part of their working agreement or Definition of Done. Once some action has been taken you can loop back to the Observe step and keep looping.
