Technical debt: it appears during an incremental cycle, during building a product or a service to bring value to the customer at the requested time or earlier. It could alter the outcome of the increment, and the team is managing the debt. You can find more definitions about ceremonies in SCRUM (one of the most known Agile frameworks - here is an article about Scrum Sprint) here.
Usually, teams are taking decisions about ‘Tech Debt’ and because no Agile Retrospective ceremony is happening at the end of the sprint - no one learn from mistakes or how they can improve and they blame themselves because of a poor decision even if it was the best decision that they could take at that moment with the information that they had.
A few years ago, I’ve built a house buying services from a constructor. I’ve discussed with the electrician and decided where to create all ditches for pipes in the walls for creating the channels for the internet cables.
The constructor put small pipes in diameter and put the cables through them almost by pushing - is a simple technical debt
1. The network cables in the wall are not of a good quality - the speed is slow.
2. Network cables are not covering all the house corners.
I’ve used a wireless router but could not cover the entire house, and there are electronics that didn’t work with slow internet connections.
This solution is of any help? Yes, in a way… but not all the electronics worked as they should. And now it's time to figure out which are the priorities - it wasn’t the only problem that we’ve had :(.
(approximately 4-5 hours of work)
And now there is a technical debt that needs my attention. But this is in a context with all the other priorities.
What could I have done from the beginning?
(approximately 3-4 hours of work) - with no other amount of work on this issue
... the number of problems is a finite number, but the solutions outnumber them! - this is what an agile growth mindset is all about.
I was looking for an unknown wireless technology that could cover all the corners I’ve needed.
(approximately 3-4 days of work)
Do you see how Technical Debt creates additional work (in percentage is over 1000%)?
I’ve taken a poor decision and another one and then others I’m adding down the road. This happens in our professional work day by day, consciously or unconsciously, until we figure out what steps we can take proactively.
These decisions which may not lead to the best choices often end up creating more work in correcting those choices, and we add more Technical Debt.
By making, a retrospective (more details here) - this is an activity that breaks the pattern - I see what I could have done better or how I could have made it right from the beginning. Thus, I needed to:
Technical Debt is fundamental at the level of an agile team in how we handle tasks - sometimes it can produce frustration between members of a team, but we have everything that we need to "face it" or to prevent it.
Some (final) thoughts
This article is part of a bigger topic called: