The Technical debt
It happens on regular basis that former technical and/or architectural decisions cannot handle with new challenges. We call it the technical debt.
On one hand, the technical debt affects the delivery speed and is considered as generally bad.
On the other hand, the technical debt means that:
- The product outgrew the technology: the business goes so well that single DB is not enough.
- The Developers had respected the “good enough” principle and had picked the “bare minimum” technology in the past. That technology actually did a decent job by bring us to the state which requires improving!
Trying to foresee all the future needs is pretty risky: there’s no guarantee that the increment will be successful enough. Let’s not overengineer.Deploying the Wordpress on AWS
- In many cases, the team deliberately made the decision to accept the technical debt. E.g., to gain some speed.
✏️Note
Ignored technical debt is bad and will bite the Team’s back.
Known and managed technical debt is a part of the process.
It’s often considered that the technical debt is on Developers and on the TechLead.
I disagree because it affects the whole Team and the Product one way or another (mainly affecting the delivery speed). Moreover, it’s important to communicate the technical debt on different levels so it won’t become a surprise before an important deadline.
The logical debt
Despite of it’s not an official term, I’d like the notion of the logical debt. It appears when the problems the team is solving are not aligned with the real issues the customers/stakeholders have.
The logical debt is more dangerous however less transparent:
- The process looks fine from the inside: the team is busy, the delivery is on time. But the product won’t be sold because the customers don’t need it!
- When the logical debt is detected/recognized, it’s already too late: the precious Developers’ resource has already been spent.
As you see, the best way to tackle the logical debt is to prevent it from happening 😎
How? — by actively getting feedback: inviting the customers and stakeholders to the Sprint review, continuously clarify the requirements.
The customer is not the enemy. Really.
© Agile values
Customer collaboration over contract negotiation