Is it Ever Okay to Intentionally Acquire Technical Debt?
The Agile Mentors Community members had a lot to say about purposefully acquiring technical debt based on the following scenario:
**You have to get a feature out in time for a trade show, so the team cuts a few corners to make the date, but ends up with several bugs in the backlog. What do you think…
Is it ever okay to intentionally acquire technical debt?**
Stick with a Proof of Concept
A Texas-based agile coach pointed out that a proof of concept may be a better alternative than cutting corners to quickly build a buggy product.
“I’ve always wondered why we have to build something faster for a show if proof of concepts look just as good and can be less buggy? Give the [team] the time they need to finish building the right product without cutting corners,” she says.
She adds that no one ever comes back after selling a product at the tradeshow to tell the team to go back and take the next six weeks to knock out the technical debt.
Define Technical Debt
A California-based agile coach pointed out that technical debt can take on many different meanings, depending on who you ask, so it’s best to define it first.
“Many people consider tech debt a function of their belief that the product is of compromised value when it is anything short of the full-blown big-bang release,” he says.
“Do we mean we’ve delivered a solution to a customer’s problem that isn’t choc-full of bells and whistles that they might eventually want? I’d say if we believe in simplicity and maximizing the amount of work not done (and then building on that with more work as the customer asks for it), then showing a slimmed-down version of the solution is perfectly acceptable, if not preferred,” he adds.
Look at Risk vs. Reward
A member from the UK said taking a product with known bugs to a trade show is a risk/reward decision that must be carefully considered.
He says, “I think I’d weigh up the options if you’re taking untested and/or buggy code to a trade show, what are and how serious are the bugs? Will it put potential customers off? What is the cost of reworking and getting the true functionality? Would we be better demonstrating a roadmap? Are we sure we can rework and release in a bug free fashion to meet the expectation we’re building? Can we use A/B test or phased releases to prevent impact on people away from the trade show and/or feature flags to disable it quickly if it causes issues?
Sometimes Tech Debt is the Best Choice
A Scrum Master from South Carolina says, “Every situation is different and should be evaluated based on it’s own merits. However, to the question of acquiring tech debt intentionally, yes, it’s ok. And sometimes it’s the best course of action.” She adds, “Debt is debt, technical or otherwise. Some debt is acceptable (a mortgage). Other debt is not so good (high interest credit card debt). And some debt is fiscally responsible (taking on debt when it’s at a lower interest rate than your savings is paying).” “The same logic applies to tech debt,” she continues. “A team should consider the cost of the debt when determining the best course of action. I would suggest it usually doesn’t make sense to operate with zero tech debt. The cost of maintaining zero tech debt simply doesn’t justify the expense through equivalent added product value.”
To join the conversation and to be mentored by more than 4,000 agile practitioners from around the globe, join the Agile Mentors Community. Visit https://www.agilementors.com for more information on membership.