Most technical professionals can agree on at least one thing: that things would've been done better and problems would've been solved quicker if they had more time to work on them and if they knew the how negatively the impact of not dealing with these issues would effect software quality. However, non-technical stakeholders struggle with this concept. The concept we are referring to is technical debt.
Although the technical debt metaphor was created to enable understanding between technical and non-technical stakeholders, it was never meant to be a model that fully explained how to manage this particular problem in software development.
Here are a few illuminating scenarios that alter how developers have to deal with technical debt:
The relationship which software suppliers have with their customers often informs how they can deal with technical debt. This relationship is often harmonious but is not always the case. There are instances when a software supplier and their customer have a tense relationship and these instances the customer will find a reason to give their software supplier a hard time: this often boils down to technical debt. When supplier and customer start discussing technical debt - its cost and scope - the customer can use tech debt to give their supplier a difficult time.
In the customer's eyes the supplier should be doing their job perfectly and technical debt should not have bee accrued in the first place. Due to this assumption, the customer does not want to pay for technical debt and will not accept any impact that the debt has on the original cost, scope, or timeline agreed on. Therefore, the supplier takes on longer hours and more effort without payment and pressure from the top to ensure the profitability of the project. Reductions in quality thus become inevitable. Authorization for dealing with technical debt can be revoked either because stakeholders do not understand the impact of not dealing with the debt or they don't think it is important enough. The development team will have low morale and the product will have lower quality than it should.
Another scenario is when you are working on an agile project that seems to be agile only in name, and is actually a waterfall project. This is the case if there are persistent worried looks when a team doesn't meet its sprint goals or if technical debt is seen a scope creep and seen as an entirely bad practice. Technical debt is something that will always occur in a project and should be dealt with in capacity planning. When the process for accepting technical debt is more prolonged than the process for actually paying it back, you have to ask whether you are actually working in agile.
Going on with the topic of how agile projects deal with technical debt, you may find yourself working on a team with an "agile activist". An agile activist is someone who is hell-bent on proving agile is the one true way of development and therefore focuses on delivering business value above anything else. When the sole focus of project is on purveying business value, continual improvement on code can be eschewed in place of shiny new business functionality. Once again you will find yourself in a position of having to ask for permission to deal with technical debt and build a case to demonstrate the business value of paying of technical debt.
While there is a case to be made for the business value of paying back technical debt (your projects quality and ability to expand and take on new functionality improves when you deal with technical debt), it means expecting that the people you are presenting your case to have an appreciation of the effort it takes to build quality software.
To read the full post visit here.