A common problem in the world of software development is bringing Technical Debt to the forefront so that organizations can clearly see why they need to make the move towards Agile and DevOps. The issue is, how do we get everyone in the organization on board? Even when you explain to the business side that research has shown that organizations of all types and sizes are having to spend 70% to 80% of their entire Software Development budget simply maintaining existing code, they don’t believe this includes them or they simply don’t fully understand the issue. The problem is that they see the requests they make to Software Development moving through the Software Development process and believe this is all new work being created for their customers.
On the other hand, Software Development generally has a suspicion that they are probably taking on Technical Debt, but due to lack of time, resources or simply the lack of will they ignore it. Even when some Software Development groups are introduced to tools such as SonarQube and its Technical Debt plugin they often times choose to ignore it or are scared to see what it will show. The truth be told, you really can’t blame Software Development for wishing this subject would stay buried, because they are often times overwhelmed with their current work load and the last thing they want is perceived additional work.
I think a major reason for Technical Debt not having the focus it should have by all organizations is the lack of understanding of what the most important ROI in terms of their software products is. The most import ROI is life span of a product, why is this you ask? When we develop new software initially we have costs associated with resources to develop it, infrastructure, marketing etc, etc… and then we have continuing costs for maintenance, additional features, infrastructure, etc, etc. The only way to recoup these costs and have an acceptable ROI is for the product to have a long enough life span. We then must take into consideration what is one of the biggest factors in the life span of a product, its Technical Debt.
So how can we go about bringing Technical Debt to the forefront so that an organization can properly prioritize it and adopt remediation processes to deal with it (Agile and DevOps)? One possible way is through the use of “Value Proposition Cards”. In order to explain Value Proposition Cards, we are going to use Kanban in our example. When we create new cards for our Kanban board we would now start marking these cards as one of two types, a “value proposition card or a failure proposition card”. So, what constitutes a value proposition card or a failure proposition card? Well a value proposition card would be any work that we can clearly identify as adding say a new feature (cannot be a re-do of an existing feature), a new application or say framework changes that are not being done to fix Technical Debt or limiting factors of the existing framework. Failure Proposition cards include obvious things like bug fixes, feature changes due to not meeting the customer’s needs, Technical Debt or framework limitations. On top of marking the cards as Failure Proposition cards we would also do some root cause analysis so we could categorize why the card is marked as a failure proposition card, in order to justify why its considered a failure.
I wouldn’t recommend going to deep into the root cause analysis, we just want to be able to explain why its marked as a failure card and have justification when the organization objects. If we were to also say, make the Value Proposition cards blue and the Failure Proposition cards red and laid them out on a Kanban board, what do you think your organizations board would look like?