Quality and Technical Debt

I have no idea why you want to, or want tot allow to, deliberate introduction of technical debt, but for sure it is a decrease in quality, robustness and predictability of the system.

If you have set quality goals, or incorporated quality in your Definition of Done (which I personally like to do), for sure it decreases your quality goals.

If for some pressing reason, technical debt has been knowingly introduced, I would advice you design a PBI ta have this fixed, preferably next sprint.

I have seen it happening in my projects as well, cut a little corner for various reasons, but at least we always fixed it the sprint after. Of course in alignment with the PO

isn't the deliberate introduction of technical debt a potential decrease in the quality goals?

Yes, but perhaps less so than the unmanaged and unplanned introduction of technical debt. If it is incurred deliberately then there may be a better chance it will be accounted for and remediated.

I've typically seen Technical Debt defined as four quadrants along two axis. One axis is how deliberate introducing the technical debt is and the other is how prudent introducing the technical debt is. You end up with Deliberate Reckless, Inadvertent Reckless, Deliberate Prudent, and Inadvertent Prudent.

Inadvertent Prudent represents learning - as you do the work, you learn better ways of doing the work. Hopefully you are sharing the knowledge across the team (to people who may not have been as close to the work) and across the organization (to other teams doing similar work). However, due to time constraints, you may not be able to go back and fix up the work, but you know how to.

Deliberate Prudent is when you know that you need to introduce technical debt in order to meet some need. I think a good example is when you need to provide functionality in your product by a certain day - consider tax preparation software in time for tax season or an online marketplace in time for the busy holiday shopping season. You fully understand what you are doing and the consequences, and have decided that it's better to take on technical debt and ship the product with intended features rather than not.

Deliberate Reckless is knowingly introducing technical debt, but not for strategic reasons like what happens in Deliberate Prudent. In my experience, high pressure situations and firefighting modes of working may lead to this. There are situations where you should push back on pressure to work fast and cut corners - not pushing back leads to this type of technical debt.

Inadvertent Reckless is simply not knowing and not learning. Not understanding your environment, your tools, good practices and principles - all of these fall into this category. You should be planning time to maintain technical excellence (it's an enabler to agility). This probably has the most negative impact to quality - you may not be aware of issues that you are introducing, both in the now and for future work.

The Scrum guide emphasizes the importance of quality and how one should aim to increase it. In some form or manner, isn't the deliberate introduction of technical debt a potential decrease in the quality goals?

I don't think that saying the introducing technical debt, deliberately or not, is a decrease in quality goals. I'd say that reckless introduction of technical debt is a much greater problem for teams and the products they deliver. Strategically introducing technical debt and having an appropriate plan to pay it down is necessary in some cases.

We have deliberately took shortcuts to introduce something we view as an experiment.  We need to put something in place in order to gain feedback from a wide user base on the efficacy of a solution or to gain validation of a theory.  But in all cases we create a Product Backlog Item to remove the experiment and another to turn it into production quality.  Depending on the results of the experiment, one will make into a near term sprint and the other will be deleted. 

There are two values for technical debt. This same statement can be made for a new product feature or enhancements to current features.  Negative as long as it exists and positive when it is corrected. Look at that in retail terms. Sometimes you have to discount something below profitable in order to pull customers in.  But it is usually a short-term occurrence where the situation is rectified in due time.

Yeah, I know. Sometimes my views are a bit strange. 

This is really interesting Daniel! I will give a try with this!

Relating this back to finance, you can have 'good' debt and 'bad' debt. For good debt,  think something that can make you money, build your brand, etc. I add debt to my credit cards in order to get free travel but pay that off before interest accrues so I don't incur potential bad debt. 

I like Daniel's example a lot since the team incurred some 'good' debt in order to validate some experiments against the market and understood they'd have to pay that back. 

Another example could be development teams who are leveraging techniques such as feature toggles. Adding in the toggles is a form of technical debt and should be removed once the feature is validated in production, however, it adds value to the users since they're able to perform dark releases to subsets of users in a real environment. 

I think the point is...we can accrue this debt for a short or long term benefit but must look to pay it off before it turns bad. This takes discipline from the development team to actually pay the debt back. 

Thomas also said it well in his post. 

Strategically introducing technical debt and having an appropriate plan to pay it down is necessary in some cases.