Technical debt, one of the key drivers of slow delivery, is rarely understood by non-technical business people. Even rarer are companies who have a strategy to reduce technical debt, which has been jointly agreed to by both business and technology groups. Debt is viewed as a problem for technology to address, not a systemic issue. Unfortunately, this leads to longer cycle times, higher costs, and lengthy time-to-market. The DevOps focus on continuous improvement is displaced by behavior that leads to continuous worsening. For companies to improve, the reduction of technical debt must be understood and addressed as a systemic issue.
What Causes Continuous Worsening?
There are a number of activities that companies engage in regarding technical debt that cause performance to get worse over time, including:
- Little or no data on technical debt, cycle time, or quality. Without data on technical debt, cycle time, and quality, it is impossible to know where to focus on debt reduction. Technical debt can be measured reasonably well through automated tools like Sonarqube.2 Agile cycle time is harder to track, but doable. Companies will often track issues in production as well as change-related issues. When an organization has this data, they can begin to see correlations between debt, slow time-to-market, and quality. Without data, it is hard to make a convincing argument for debt reduction or automation. If you can't see the impact of debt, why would you invest in reducing it?
- Fixed scope, fixed date initiatives with limited or no team involvement in estimation. Surprisingly, some companies still engage in this practice, which leads the quality and people suffer. The pressure to produce conditions teams to take shortcuts, ignore poorly designed code, skip automation, and reduce testing. This pressure also causes teams to make coding and design decisions that ultimately increase debt, thinking they’ll get a chance to revisit it and improve it later. But later, they are under the same pressure to release new work, and thus, a negative feedback loop of increasing debt is created.
- Product Owners and Product Managers with no technical background. While in the past it might have been acceptable for product people to have scant understanding of technology, it is no longer acceptable today. Most products have a technology component or require technology to sell and service them. Product Owners with no understanding of technology, technical debt, and its consequences will struggle to be effective as the backlog owner for a technology team. They'll make bad decisions with unintended consequences. Fortunately, if they are willing to learn, most of what they need to know can be easily learned over time.
- Lack of understanding that employees leave companies that have poor technical practices. In today's marketplace for technical talent, people have a variety of choices in where they work. Simply put, companies with poor technical practices lose employees. Working on poor codebases with little automation can be fatiguing, and ultimately decrease satisfaction and engagement.
Ways to Reduce Technical Debt
Recommendations to evolve towards a culture that understands and effectively manages its technical debt include:
- If you are in a technology group, educate your business counterparts about technical debt and its consequences to help the business as a whole make better-informed decisions.3
- Decide where to focus your effort on technical debt as an organization. The high growth product in a volatile market is probably a better choice for increased automation than something close to being sunset.
- Align on how you'll measure technical debt and its consequences. Specifically decide who will review the data, and how frequently.
- Talk within your teams about planning for debt reduction, and commit a specific percentage of your time to focusing on debt reduction and automation.
- Use facilitated value stream mapping workshops to understand where your value delivery is impeded.
Summary
A lack of understanding of technical debt and its consequences can slow progress to faster cycle time and improved quality. It is a business problem. By discussing debt, its consequences in your company, and how it can be reduced, you can create a culture in which improvement is a focus, and your investment in improvement pays off.
-
Carmichael, Sarah Green. “The Research Is Clear: Long Hours Backfire for People and for Companies.” Harvard Business Review, 28 Dec. 2015, hbr.org/2015/08/the-research-is-clear-long-hours-backfire-for-people-and-for-companies.
-
https://www.sonarqube.org
-
In one organization where I coached, I used the analogy of a messy garage when describing technical debt. "Imagine you have a project you want to do at home over the weekend. You go into the garage, and it is a mess. You can't find the tools you need, and you go to the home center and buy yet another paint tray and roller handle. You have to move around things to create room to work. Even if you know where something is, it is not easy to get to. Everything takes a lot longer than you would have guessed. This is roughly what it’s like to work on a bad code base."
