Why Technical Debt is like a game of Jenga and what can Scrum Masters do about it
What is Technical Debt??
Well, technical debt is a metaphor developed by Ward Cunningham in 1992 to communicate problems due to “not developing in the right way” with non-technical stakeholders. To put it simply it is a loan you never intended to take.
Why should your IT landscape worry about this??
Well, to draw a parallel technical debt is very similar to Financial Debt and we all know how dangerous and potent a thing that is.
Technical Debt costs companies money and decreases efficiency which essentially means that everyone from developers to customers has to pay for the cost of technical debt in the system. Technical debt incurred over a period of years starts making maintainability of the code in production systems a costly and time- consuming affair along with also having possible side effects like bad system performance.
The more customized & unstable the code is, the more technical debt you have and the more time and effort you need to spend on the upkeep and maintenance of the code. But the correlation is not always linear and easy to calculate, which sometimes lets the debt lurk in the background. Also as the team progresses with the same pattern of development it becomes more dependent on specific developers who are the only ones able to maintain it.
And like an addiction, once you incur technical debt in your code, it just does not stop and you keep on incurring more until a point where adding anything new is like playing a game of Jenga where you don’t know if the last change will topple the whole thing over.
The bottom line is that technical debt is slowly but surely killing the system you work with. Hence the more you think about it the more you can understand the relevance. If it is not clear maybe the picture below can shed some light on this-
What can you as a Scrum Master do?
- Start the conversation on Quality -Challenge the team enough on Quality and check if the team is abiding by the quality over speed principle or the Built-in Quality SAFe principle. Be mindful and observant in the refinements for compromises being made and question them. For example, if you see the team taking a shortcut and that is being accepted then ask the reason behind that. Though one should be mindful that in some cases debt cannot be avoided. In those cases, it should be incorporated in the strategic design or the architectural runway.
- Limit WIP — Discuss with the team(including the PO) what they think can be delivered with good quality and structural solutions and enable the customers in the right manner. This may sound like velocity but while velocity is measured in terms of the amount of work, WIP is all about the unit of work(eg. the Count of user stories at any stage of development which the team is confident of working upon at one time ). Encourage the team to choose their WIP and work according to that in the team.
- Enablers- An enabler(as per SAFe) supports the activities needed to extend the Architectural Runway to provide future business functionality. You can have a discussion with the architects in the team and also the team to have an overview of the technical debts they may have incurred along the way. Enable them on the thought process so that they become increasingly self-dependent and have the right mindset for quality. You can create a separate category for the enablers at a feature or user story level or create tags as per the agreement in the teams and then have discussions over a period of time over a dashboard view.
- Root Cause Finding- If the team faces an issue due to code quality make sure that you facilitate the root cause session in a manner that helps the team understand the root cause and also come up with definitive actions. The 5 why analysis has proven to be a good method for me.
With these 4 checks as a Scrum Master, you can guide your team towards a stable and mature system.
Technical Debt while unavoidable in some cases should never be a symptom of a quick fix that enabled crappy code delivery to customers. These are my thoughts on technical debt, its impact, and what can be done to minimize or prevent it. Do let me know your thoughts on this as well, looking forward to the comments. :-)
