I suspect quite a few of you have come across this model before:
Known as the Iron Triangle, this model describes the conflicting trade-offs you’ll face when managing a development project.
The Iron Triangle makes good sense: a product with more features will take longer to create, which means it will cost more. Likewise, if you want something sooner, you’ll find yourself choosing between decreasing the scope or increasing resources, which again, will cost more.
A common project management practice is to ask the customer which two of the three they want, because you can’t achieve all three. We know that if a customer wants a high quality product with lots of features, for example, then they will have to wait a while for it.
We’ve all been in this situation at one time or another: your release is running behind schedule. According to the Iron Triangle, you have three choices.
Okay, we’re among friends, so let’s be honest with ourselves. There is a fourth option, a hidden “fourth side” of the triangle. What about sacrificing quality in order to keep the project on track? How many of you would consider one of these a “temporary fix”, “a quick fix”, or even a “dirty slimy hack” in order to achieve a target release date?
In fact the Iron Triangle is often pictured with the word quality in the middle of it. This represents the fact that when the triangle gets out of shape, it’s quality that will be affected first.
This is exactly what we don’t want.
Firstly, there’s the obvious potential for bugs. Not only do these reflect badly your business reputation, but they also represent a huge efficiency loss. The development team gets redirected to bug fixing and releasing patches, rather than adding value to the product. Instead of moving forward, development gets stuck.
In addition, bugs bring the additional costs of your account managers apologising to customers, while your service desk staff are busy raising issues and investigating the nature of the bugs.
2. Sacrificing speed
Secondly, there is also the fact that future speed of new development will be impacted by these so-called ‘shortcuts’. Your codebase will be scattered with areas of the code that will need to be rewritten at some point in the future, and there’s going to be a cost in doing that.
Any bug fixing work is also going to take a lot longer than it needs to, especially if the code isn’t covered by unit tests, comments that make sense, or code that hasn’t been refactored.
3. Lack of documentation
Thirdly, it will inevitably lead to a lack of documentation and lack of proper architectural consideration. This may seem like a small detail – it can all be coped with while the developer who wrote the code still works for you.
If they leave, however, unpicking everything can be extremely painful. Quite often large areas of code need rewriting, which will always have unexpected impacts on your schedule.
All of the above issues fall under the umbrella of ‘technical debt’, and this ‘debt’ can build up gradually in secret, increasingly slowing development down.
To avoid technical debt creeping up on you, you can introduce practices to make the debt transparent and to make sure you spend some of your resources dealing with it.
Visualisations of work helps keep teams on track
To finish up, let’s take a look at some of the best ways to use JIRA to avoid technical debt.
1. Each time there is unfinished work, create a JIRA issue, give it a priority, estimate it, and work with the Product Owner to prioritise it on the backlog. The longer you leave it before dealing with it, the more expensive it will be to eventually fix it.
2. Educate the Product Owner about technical debt, and how it can slow down the efficiency of development teams, so they are aware of its significance.
3. Measure the number of bugs found in production, and the amount of time it takes to fix them. If there is an increasing trend of either of these measures it might indicate a build-up of technical debt, but you’ll be aware of it early and should catch it before it escalates.
4. Measure the growth of debt and create a ‘Technical Debt’ issue type to log this kind of work against. You can then report size of it in the backlog, and whether it’s growing or shrinking over time.
5. Take the opportunity to fix technical debt when you are modifying affected areas of code. This may mean that changes take longer, but overall you will see real benefits.
What are your tips for managing technical debt? Let us know in the comments!
Become a JIRA Superuser and tackle your technical debt!
Join Clearvision’s JIRA Fundamentals and JIRA Superuser – London, 29-30 November. This exclusive, two day intensive training course combines Clearvision’s JIRA Software Fundamentals and JIRA Software Superuser courses and teach your team everything they need to know about working with JIRA.
Spaces are limited: reserve your place now.