No Product Owner likes paying off tech debt. It looks suspiciously like the Devs messing around with perfection when the product is already working. The team could be building me new features dammit!
Tech debt is a pretty abstract concept to people without a coding background. We want to communicate it in a way that explains the value to the PO, in terms that are meaningful to them. Here are two approaches – one that I've used before and that worked, and another that I mean to try next time.
Tried and tested – the car service
If you drive a car, you get it serviced every year. It's painful because (a) it's expensive and (b) your car's still running. Yes you could drive it to Birmingham next week without getting it serviced. And the week after. And the week after that. But it will keep getting a bit slower and a bit more expensive to run, until one day it stops. And it won't stop gently on a day that doesn't matter – it will stop hard on the motorway when you have to get to Birmingham in a hurry. Because that's when you're stressing it hardest.
Your codebase is just the same. Sure you can put off paying off tech debt, because it's still running. But dev work that should be easy will get slower and more expensive, until one day you can't go any further.
If your PO wants to keep driving, they've got to service the car. Otherwise expect it to come to a screeching halt just when it matters the most.
Next time – revenue protection
Product Management types understand two broad categories of project:
- Revenue generation
- Revenue protection
They prefer revenue generation projects. Everyone does – they're sexy and pay all our bills. But they understand the need for revenue protection as well.
Paying off tech debt is revenue protection for the workstream. Or maybe velocity protection. Without it, once again work will slow down until it can't go any further.
Can we avoid this in the first place?
Of course it's better if you can avoid having to commit time to paying off tech debt. In a steady-state business-as-usual workstream with frequent releases, ideally the team refactors the code as you go to avoid getting into this situation at all.
However sometimes you have to accrue tech debt – eg there's a cost-of-delay driving an MVP release. Or you'll discover it some time later. When that happens, you'll want to convince your PO to give it appropriate priority.
Guy
Makes me think of the Intel tick-tock model (https://en.wikipedia.org/wiki/Tick-tock_model), with revenue generation being a new micro-architecture to support saleable new features (which might demand increased clock speeds and a higher transistor count), and revenue protection being updating the fabrication process needed to allow those higher clock speeds and transistor count while maintaining reliability and manufacturing yields. But this is obviously contrary to the idea of refactoring as you go along (is there a clear preference among developers for that? I really don't know).
ReplyDeleteCloser to my particular area, there are also clear parallels in data quality, as per this post (https://michaelbaylon.wordpress.com/2009/12/29/technical-debt-what-about-information-quality-debt/).
Thanks Graham. Yes I agree there's a similarity to Tick-Tock, with the Tick phase (shrinking the existing chip architecture) being similar to paying off tech debt, so enabling the next Tock (the next generation chip architecture). Perhaps an even greater correspondence to Process-Architecture-Optimization, which replaced Tick-Tock in 2016:
Delete* Process – Tick
* Architecture – Tock
* Optimization – Tech Debt
I absolutely agree re data debt on two levels: cleaning up existing data points and cleaning up the data architecture itself.
Guy