Agile software development methods have become more popular in recent years as development cycles shorten and competitive pressures mount to deliver quicker. Unfortunately, Agile technical debt tends to pile up faster than we can pay it back. You see, with Agile, the objective is to deliver working software in a short time frame with each iteration ‘working’ for the customer. Sometimes we get defects, yet we have ‘working’ software. We all want minimum overhead and maximum value “working software over documentation.” Unfortunately, with each iteration, many times we can’t fix the defects and have to put it into the backlog. Any work item in backlog should be described in detail enough for those that need to work on it.
Agile Technical Debt Piles Up with Defects
So in Agile, YES we do have Agile defects and yes we need to file them. The more clear and concise, the faster they can be fixed. As a QA working on an Agile team, the most important thing is to write a defect clearly and quickly and, of course, ensure that it is valid. Any defects that don’t get fixed can also be called technical debt. Defects are the ultimate form of technical debt. You may think that some defects don’t need to be fixed, and that is true depending on the severity and the risk involved. However, especially for structural defects or defects that stem from bad architecture or can’t be fixed easily due to bad architecture, it is easy to pile up debt. What is our debt now in the USA, $18 trillion? And by the way, when you hear government officials mention the term ‘reducing’ the debt, that actually means reducing the rate of increase! The problem with Agile technical debt is that the interest rates can be very high and uncontrollable once your end users loose faith in you and your software.
So, with defects in Agile, if you don’t write them up, you find that you get into Agile technical debt without knowing how much you owe! Not a good situation to be in.