It is common that technical debt in its various forms is hidden within any system. Known or not tech debt often gets brushed aside in favor or other work that is more easily quantified and valued. Typically, there are many excuses as to why we must endure those that we know of or remain oblivious to those we don’t. These excuses range from “that is not as important as ‘XYZ’” to “we could do that ‘someday’” along with countless other reasons.
- Well, ‘XYZ’ dragged on forever and then flopped – either because of technical debt or created more of it.
- ‘Someday’ never seems to arrive so you still have that technical debt lurking and hindering your ability to perform as well as you could.
- We suspect there are things we could improve on, but have no idea what they are, what the impact is, or where to start.
It is typical to favor more exciting feature work over the likes of fixing crippling problems. Though important, modernizing systems and refactoring is just not all that sexy. These things will bite you hard eventually if ignored long enough and it will likely hurt a great deal. Delivering a shiny new feature on time is often tied to someone’s performance review. This bumps dealing with technical debt lower in the priorities even when it harms the ability to deliver that feature.
To be fair though there are two main categories of technical debt. The first involves deliberate or intentional delay of known corrective actions due to other perceived priorities. The other is more accidental because we just don’t recognize it as a problem. This might also be attributed to a lack of awareness around the cost or impact or just unwilling to invest in digging deeper. Both are indeed bad and will hurt the same. Knowing you have technical debt and ignoring it is a recipe for eventual disaster.
Often referred to as ‘Dark Matter’ technical debt adds to your risk and is always present. This is largely due to the fact that we are continually learning and our system evolving. This has a significantly negative impact on your business by consuming some percent of capacity. It typically represents time lost, effort wasted or other inefficiencies that manifest as hidden costs, delays in the delivery value. Awareness of technical debt and its impact on the business is essential to performance and ability to compete. Even more important though calculating the impact and reserving capacity to relentlessly attack it.
Some of the forms of technical debt (aka ‘Dark Matter’) that might surprise you that could be strangling your business:
- Code fragility & complexity – needs some serious refactoring
- Product Documentation
- Manual processes that could/should be automated
- Relevant automated testing – testing because you can even if it is excessive or irrelevant
- Out of date skills, tools, practices, …
- Poor usability or design
- Outdated Architecture
- Outdated organizational structure
- Employee engagement
- Test suite relevance
- Data sources, quality, and relevance
- Feedback channels – as in out of touch with customer data or feedback
- Lack of formal process involving technical debt
Problem is that ignoring technical debt can be ruinous to the business in many ways. Your company could be suffering real harm with negative impact on costs, performance and even employee retention, engagement or morale.
Some additional insights about the impact of technical debt that you might not want to know:
- Limits innovation potential
- Higher maintenance costs & negative impact on engineering capacity
- Lower employee morale, engagement and retention
- Customer frustration with quality and/or velocity of deliverables
- Ability to be or remain profitable and competitive
Leaders that both talk the talk AND walk the walk
All too often tech debt elimination sounds great, but in most cases dies on the vine due to other business pressures. Leaders that want to see real change need to buy into the process and tolerate some organizational learning. Leaders need to not only authorize change but inspire such changes to happen. Ideally leaders can identify some higher-level problems to explore. Then go solve them to lead by example and broadcast the results far and wide to inspire more.
Supporting a Community of Practice that is populated with enthusiasts that meets regularly is a huge first step. Such a group would be focused on technical debt or Flow Engineering speaks volumes around a commitment to improve. The empowerment of others to run with driving improvements improves engagement and morale.
Go beyond the typical performance review process by working improvement target goals into the mix. Then ensure people have the support from above as well as the capacity to make the magic happen.
Better Balance
As part of a healthy Value Stream mindset both the Flow Framework and Flow Metrics are important for balance. Better balance of work item types ensures that technical debt elimination efforts are not overly invasive. By devoting some percentage of capacity each sprint then you are at least making progress. Start with a small percentage like 10% (20% is ideal) so as to not be overly invasive but still get results. A more balanced approach also brings with it the benefit of staying current and reaping the benefits along the way.
Bake in some relevant metrics
If you want to have better balance regarding technical debt, then set performance related metrics, make them part of organizational metrics and then make them relevant to individual performance reviews. Teams and/or individuals can break this down further and translate performance goals to something that they can contribute to. Doing so gives those in the trenches the authority and opportunity to align with organizational improvement goals and attack technical debt as part of their day job and not an afterthought or crisis event.
There are several interesting and relevant metrics involving technical debt. Such metrics enable data driven decisions that can influence priority of technical debt elimination efforts. Here are a few that that help to get a handle on the tech debt situation:
- Technical Debt Score – quantifies the technical debt within a system
- Technical Debt Ratio – reveals the cost of fixing existing issues compared to the cost of delivering new features.
Contact NRM to learn more about what other technical debt metrics would be appropriate for your unique situation.
Empower the people
Most people would prefer not to accept the status quo and keep doing the same painful or inefficient thing over and over the same way. You hired smart people, so tap into those smarts and empower them to take ownership and drive improvements in how they work. Even if your teams are doing well with retrospectives and making improvements, many may not feel they can or should take on deeper problems that go beyond team boundaries.
In many cases they may feel they need approval, space or other resources to do such things. In other cases inspired change might span teams or orgs suggesting there is a need for broader buy-in, involvement and effort.
Consider Tiger or System Teams
When you have significant, invasive and urgent technical debt problems to solve it can really help to declare and empower a Tiger team to go solve it. In a nutshell these are small, focused, short duration teams on a mission. Such teams are populated with the proper skillsets that are on a mission to solve a problem or enable a needed capability. This sort of effort pairs well with Kanban or FaST Agile which tweaks the normal pomp and circumstance of agile in favor of rapid results with dynamic teams.
You will have to make some sacrifices and allow those involved to be fully dedicated to this quest, but it will be well worth it. Many are likely to welcome a break in the action of the “day job” in order to work solve a problem by making creative contributions in other ways.
At NRM an important part of our approach to technical debt involves awareness and making it a first-class citizen of your product backlog. Chipping away at that iceberg with deliberate incremental progress will pay dividends quickly that continue to compound over time. Otherwise, ignoring the iceberg of technical debt will likely sink your ship eventually.
Flow Engineering concepts help to reduce technical debt in several ways. First are the Flow Engineering maps that help to raise awareness, increase focus and generatively pave the way forward the right solutions. With a highly collaborative element Flow Engineering ensures that the people involved in the target process (you know, the ones that most likely know it best) are involved in creating the best solution. As a result, a proposed improvement has more focus, clarity and buy-in all of which combine to amplify your chances for meaningful success.
Conclusion
Dealing with technical debt versus ignoring is essential for business success and starts with acceptance and awareness. The lack of a formal process focused on the elimination of technical debt only ensures that tech debt will prevail continuing to grow until it triggers a major event.
Contact NRM to begin exploring your technical debt situation and help formulate a plan to pay down your technical debt with style and grace.
External Links:
McKinsey’s Technical Debt Score (TDS)
Technical Debt Ratio
NRM Technical Debt White paper – coming soon
Leave a Reply