The cures for Technical Debt
How could you understand that a team has technical debt? Most probably looking team’s open bug number ticket in a a time period. But why are bug ticket numbers increasing? Why can’t teams fix the root cause of those bugs? The answers to those questions may not be technical. Maybe we have to go upstream.
Too much Work In progress (WIP) is the root evil cause of the many problems. For example, if there are too many projects that are starting in an organization or if there are too many features that wanted to be added in one project, then teams become inefficient because of switching tasks and they’re crushing under the pressure of deadlines. The result growing technical debt.
Why is technical debt so bad? From a software engineering point of view code lose its agility. A programmer can not find and add a feature easily and quickly. So the team becomes in fire fighting mode, unhappy customers, and so on.
I would advise below countermeasures that worked in my life.
Limit WIP
Shape the demand. Especially from comes from C level. There is no infinite technical capacity in organizations and remember Steve Jobs famous quote, — “Deciding what not to do is as important as deciding what to do” [*]
Use classes of services (CoS) for dynamic prioritization
Prioritization is a waste in that complex world. Use dynamic prioritization by the help classes of services mechanism. CoS comes to my life with Kanban method[*]. If there are too many features to be implemented in a project, then no one looks at technical debt. In CoS there is very special category. As you can see below, its name is Intangible. Intangible means if we don’t do it now, there is impact, but impact will show itself in the long run. Sounds very similar to technical debt, right? For example, upgrading a system or refactoring etc…
Teams should take on intangible work item types (PBI) in order to pay their technical debt one by one. Most of the time, POs or stakeholders don’t see that detail.
Put policies in your system
Policies shape culture. Put visible policies and try to apply them. In below Kanban board there are two basic policy. The first one is a WIP. The second one is Intangible limit. Team says that in our system we have only one urgent issue at a time and 50% of our work should be intangible. In other words, we put a slot in for our technical debts. Great kaizen mindset.
Code review sessions
In order to decrease technical debt, you have to increase the knowledge threshold of your team. Code review sessions are great for learning.
Refactoring is a must for reducing technical debt
Refactoring is a restructure without changing functionality. Don’t forget no one could write clean code at the first time and without tests it would be very difficult to start a refactoring process.
