Her blog post hits home with me because dealing with technical debt while balancing the need to keep delivering value has long been a hotspot of mine. I even built a conference talk around it!
My talk centers around trying to deal with long-ignored, horrible debt that's threatening your organization's ability to survive. Literally. I've been part of companies where technical debt and quality issues were ignored for so long that sales of renewal licenses were plummeting, and high-visibility customers had told us to take their name and logos off our products' reference materials. In this state your developers are very likely miserable and unmotivated, your customer support group likely hates your delivery team, and your testers (if you have any) are tired of being blamed for terrible quality problems far outside their ability to resolve.
Diving into how and why organizations get to this state is a subject for many, many other talks on culture, technical and business ignorance, and the Dunning-Kruger effect, among other things.
What I can do here is lay out some guidance on how to approach building up a reasonable, actionable plan to resolve those quality/technical debt issues.
Fix While Delivering Value
The most critical thing is to build a plan that will allow your organization to resolve the technical debt and quality issues while continuing to deliver value. Full stop. Any plan that starts with "We'll just stop work and re-build this the right way" is doomed to failure. It's an awful business decision and has been proven disastrous for many companies.
Your goal absolutely must be to continue making your releases while working through your technical debt plan. Keeping the organization's lights on and the employees employed is a good thing.
Four Steps to Creating A Plan
In my talk I lay out four steps on how to create a Tech Debt payment plan and implement it. Each step's goal is to provide just enough information to move on to the next decision step. For example, the first step only determines whether or not the organization should fix the system. Nothing about costs, levels of effort, or schedules. Just the answer to "Is the pain bad enough that we should address it?"
Keeping each step very focused and Lean-thinking helps organizations work in small chunks of effort, rather than being lost in months of analysis paralysis. It also gives organizations the ability to stop at any point if it becomes clear the effort involved isn't bringing expected value rewards.
The first step in determining the plan is to get consensus on whether or not to fix the system.
Should We Fix It?
You, the developers, others in the delivery team, or others elsewhere in the organization have had enough with the codebase as it is, and want to do something about it. Immediately, if not sooner.
The Desired Outcome
In this phase there's just one question that requires an answer: Will fixing the problems bring value to the organization?
Note that question does not include a thing about the level of effort involved. We'll figure that out in later steps. What's needed is an honest, open discussion using as much factual data as you can gather. This outcome means getting the entire team together for several hours' deliberation. That discussion will likely be pretty intense, so you might consider bringing in a facilitator to help keep the meeting productive and focused.
Answering The Question
For this effort the entire team must be involved. And by "entire team" you absolutely must include everyone involved in any way with the technical or business aspect of the system. This meeting requires participants in at least all the following roles:
- Executive sponsor
- Product Owners
- Program Managers
- End Users
This list isn't a small group. You'll likely need to block out at least a half day and a large enough space to have multiple conversations running.
During the working session, you need to evaluate the state of where the business is with the software. This session is high-level. You should explicitly set a rule that no one may open up source code in any editor, viewer, etc. Questions you should consider discussing:
- Are we making money with the product? Are we getting new sales? Are we getting renewals?
- How long does it take us to get a small fix into end users' hands?
- How hard is it for us to add new features?
- What is the morale of our delivery staff? Of our support groups? Of our operations staff?
- Are we losing reference customers?
- Are our users happy or angry?
Note that we're not considering the number of active bugs. We're not looking at any static analysis code quality metrics.
We may look at metrics around time-to-fix or time-to-ship, and we should look at the number of support tickets filed shortly after each new release. We should likely look at sales data, especially around new and renewal data.
Note I listed many roles from the business, including influencers and top-level decision makers. You absolutely must include them in these discussions, because they may have insights into strategies that could dramatically impact decisions. Imagine your top executives saying something like "After hearing all the difficulties around support and the falloff of sales, perhaps we should just consider dropping this product and focusing our efforts on other higher value initiatives that are already getting us better revenue."
The outcome of this intense, difficult meeting is a "simple" thumbs up or down: Should we fix the problem? If the answer is "Yes!" then we'll next move on to figuring out what parts of the system to address.
Up Next: Determining What to Fix
In the next post, we'll look at determining what areas of the codebase to consider for fixing.
Is any of this sounding familiar? Are you struggling with this situation yourself? I'd love to chat with you and see if I might be able to help! Drop me a line: Jim@GuidepostSystems.com.