Our Scrum Master keeps referring to bugs as technical debt. Is he right, are bugs considered to be technical debt in the world of Agile?
Agile – Are bugs part of technical debt
agiletechnical-debt
Related Solutions
It is a feature.
As a [Developer],
I want to [refactor the whizbang library]
in order to [simplify maintenance and speed execution]
It is defined and scheduled and tracked like any other features.
If implementing this feature is not sufficiently valuable (to the client or to you) for it to ever be scheduled, that's a different problem.
If you can bend the user-specific requirements into something that will be useful for everyone, great. If the client is willing to pay the ongoing support costs for the feature, also great. But if you're a small team and you find yourself struggling to support all your features, there's nothing for it but to make some hard decisions about the features you need the least, and then invest some time rooting them out of your codebase.
SaaS puts you in a good position to gather usage statistics. You should look at tooling up your features if you haven't already so that you can keep a track of who's using what. Our experience is that the most idiomatic customers are usually also the most dysfunctional; that guy who stamped his feet and held his breath until you gave him an export-to-MS-Access button probably hasn't used it in over a year. Some features are kept alive even though only one customer is using them, because that customer is loud and threatens to take his business elsewhere every time something's not to his satisfaction. Discontinuing the feature might cost you a customer now, but the time consumed in supporting that feature may cost you dozens of customers over the years. It is a measure of the quality of your management team, whether or not they are willing to make that sort of decision.
When you do discontinue a feature, make sure to announce the decision to your customers (or at least those affected) well in advance, anywhere between six months and three years is reasonable. In fact if you find yourself agreeing to build user-specific features you might try to get your sales staff to build an expiry date in from the start. Call it the "support lifetime", and make it clear that the longer they want it the more money it will cost. Try to provide workarounds for your clients so they're not left floundering when a feature goes, for example a script that converts your exported XML files into MS-access format, or a bit of advice about choosing a better RDBMS.
Something that's worked for us as a preventative measure is to get a report from our sales team sent to our development team and management on a monthly basis. This report covers feedback from clients -- what features are most popular, what features are most requested, what proposed features are generating the most buzz. This is interesting if you're a developer but the real benefit is to the sales team, who are now thinking a bit more about each feature in the context of the bigger picture, instead of sending in an endless stream of feature requests and prioritizing based on which client was the loudest. The effect has been to make our sales staff more hard-nosed when it comes to new feature requests in a negotiation because they are more conscious of where each feature might fit into the overall value proposition of our product.
Having modular code with lots of automated tests will help you when you're hacking features into your product and hacking them back out again, but ultimately this isn't a programming question but a management one. Writing code to make a sale is a fool's game.
Best Answer
I think the answer here is fairly simple - the key feature of technical debt is that its something we incur by choice.
We choose to make architectural, design or implementation decisions that we expect will cause us issues later in order to achieve specific objectives sooner.
A bug is not something we choose to have in our code - so de-facto its not technical debt.
Of course one can make all kinds of interesting (and possibly valid) arguments about choices made post discovery but fundamentally (and particularly in the context of the question) no, bugs are not technical debt - sounds more like abuse of buzzword bingo to me.
As a postscript - I don't agree with the assertion that its a given that technical debt will lead to bugs in and of itself as that makes far to many assumptions about the nature of the choices made. For example you can have well written, well structured, test covered code that still makes - say - architectural compromises for early delivery. Similarly you could choose not automate your deployment processes which won't lead to bugs but will probably lead to a lot of stress and pain. Of course if the debt is that you've written code that's not SOLID (or whatever) then yes... but that's by no means always the case.