Well it is and it is not. If the defect is going to be fixed right away it is not a technical debt, and if team chooses to let it remain and plans to address it later, it can be termed a technical debt. The assumption being that the impact of the defect is limited and the feedback/learning that we get by getting the software out – far outweighs the limited impact.
This question came up in one of the Agile Scrum Workshop, for a team that’s a couple months old, with members having different levels of experience with Scrum. There is more to technical debt.
A single common backlog that comprises the so-called enablers and/or technical stories, the technical debt along with functional user stories needed clarifications and was entwined with the above question.
First the technical debt,
The metaphor technical debt was coined by Ward Cunnigham, one of the signatories of the Agile Manifesto https://www.youtube.com/watch?v=pqeJFYwnkjE Not Refactoring
Not refactoring
One of the factors that contribute to technical debt is not refactoring the code. It is associated with XP practices. When doing Test Driven Development (TDD), one keeps writing code to make it pass the tests. When we have got the code to pass all the tests, we have the functional code. Though functional, it may not be the best for enhancing and maintaining. We need to refactor the code, ideally then and there. At times we may postpone, to get it out of the door and solicit feedback, and end up creating technical debt.
It is termed debt because if we do not get rid of it by fixing it, we will need to pay an interest, it will slow our progress. A part of our effort will go towards working around this not so well written code, in terms of understanding it and/or enhancing it.
Lacking Definition of Done
Technical debt can result from conscious deficiencies in the Definition of Done. Many a times we need to postpone the integration of code developed by different teams and the related activities. This could be due to large size of the software and the development team, coupled with the team organized functionally. This is often come across along with the lack of CI/CD practices and the required infrastructure. The team’s definition of done will stop short of integration tests, requiring the hardening sprint to address these issues. Though this is often done with the concurrence of the Product Owner and will get addressed, it delays the release of the software.
The presence of hardening sprint increases the tendency of postponing fixes and parts of features to the hardening sprint, this needs to be watched carefully.
Another situation is test automation not being included in the Definition of Done. The test automation is postponed or ignored, resulting in team taking increasingly more time to test. At some point they will be forced to bring in the automation.
Learning not reflected in the code
Another form of technical debt results from the lack of our learnings and understanding of the system being reflected in the code. This happens over a period of time, when though we keep learning more about the system, but are not able to make it reflect in the system. This is often due to constraints of shipping early and adding more features to meet the market needs. This could lead to a situation that could slow down the progress to such an extent, that we will need to stop everything and address the technical debt.
In other words, all the effort starts going towards the servicing (interest) the debt, and we are compelled to address the debt itself.
So, anything that impairs the delivery of software can be termed as technical debt, though there are differing views on what can or cannot be included. One point that all agree is that Team’s must refrain from doing a shoddy job and terming the resulting shortcomings as technical debt.
The single common backlog was another concept that needed some clarity. All the work that the Scrum team needs to do has to be reflected in the backlog is a given.
The team had a situation of using a tool that was being replaced with a newer version and there were discussions on adopting an altogether different new tool. Could this be termed technical debt? No!
Would like to hear your views on the above as well the previous three points on the technical debt.
The above issue on the tool replacement gets into the realm of product visioning, roadmap and planning where the PO and Team needs to work along with other stakeholders to address it.
The single common backlog brings up an interesting point on sizing, should we size all the items in the backlog? That’s a Challenge of the Week question here.
