Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Is Technical Debt Secretly Your Scrum Member?

DZone 's Guide to

Is Technical Debt Secretly Your Scrum Member?

The spectre of technical debt hanging over your team could be what's affecting the progress of your product.

· Agile Zone ·
Free Resource

What is Technical Debt?

In simple words, technical debt is the bad engineering practice used intentionally or unintentionally while developing software which leads to adding up of complications to the existing code base which impacts overall maintainability and quality of the code. There could be innumerable reasons for such practices at the team or organizational level. Technical debt is insidious and arises in every codebase and every team sooner or later, impacting the overall agility of the Scrum team to respond to new changes.

Signs of Technical Debt

No matter if you are developing a product from scratch or maintaining a product, if your team gets into some of the situations cited below then be sure to take some actions to correct your course before your agility becomes vulnerable.

  • Your development has slowed down as your development team finds it difficult to understand code (because it is badly-written) and gets stuck with issues that were not planned.
  • Testing new features result in new bugs being exposed.
  • If the team needs the details of a certain design or feature but adequate information is not readily accessible. Also, if adding new features means writing dozens of documents. Either way, your agility is hampered.
  • Your product still runs on legacy systems and may have issues related to security or maintainability which are known to be resolved with newer technology.
  • Your development team frequently gets busy with sudden production incidents and defects.
  • You have dependencies outside the team, implying you will not be able to scale easily.
  • Your product is getting a greater number of crashes and performance issues.
  • Every time a module is developed it cannot be unit tested separately. 

Technical debt is not one person’s fault, and there is no one reason that causes it. There are many aspects both within and outside the control of a team that may have contributed. There is more than one kind of technical debt and some are planned and intentional.

How Development Teams Contribute to Technical Debt

  • Bad code invites more bad code. Every time a developer copies and pastes a bad piece of code with incorrect loops or naming convention, more bad codes gets added and there is no end to it.
  • Bad estimation with an unrealistic deadline commitment. In such situations, developers tend to choose shortcuts over good design.
  • Lack of knowledge of current best practices or absence of architectural guidelines.

How Product Owners Contribute to Technical Debt

A product may have been developed under traditional methodologies and already have a known set of technical debt. The Product Owner must understand if code behind the product is buggy, then the development team can get busy with unforeseen defects and complexities of the code, eventually impacting overall sustainability and agility of the product.

Agile means working in iterations and short burst, but too many frequent changes may supersede earlier design resulting in patchwork. Long term-vision and upcoming anticipated changes can help in projecting a better design.

Clear communication is essential between the Product Owner and development team to make such issues transparent and addressable.

How Organizations Contribute to Technical Debt

  • Lack of organization-wide architectural guidelines, tools to identify architecture debts, practices, etc.
  • Lack of will to move from legacy systems or intrasystem dependencies.

At times, it is important to launch a new feature in a very short time to gain market benefit, accepting long-term risk and making a planned debt. In such a situation, the team may bypass some key good practices to meet the deadline. But it must be kept in mind that inferior code will result in cumulative interest being accumulated. A team may choose a shorter path to reach the goal by creating messier code, but it will make consecutive journeys tougher and longer.

How to Avoid and Control Technical Debt

Technical debt is ubiquitous, so it's better to make a practice of minimizing it rather than running away from it.

What the Development Team Can Do

Development team can simply follow a few rules of thumb:

  • Leave the code cleaner than what you found. Such a thing should be a habit rather than a cure.
  • Run static code analyzers even if they don’t expose shortcomings of designs and make sure to fix all major findings.
  • The team must take some stringent actions to improve the definition of done, follow coding guidelines to reduce the possibility of technical debt, and commit to it.
  • Highlight the issue of existing inferior code with the team even if the team accepts the risk.
  • Adding automated test cases and maintain high code coverage, so some key issues and functionalities can be tested easily.

Now, Scrum is deliberately non-descriptive and leaves up to teams how they implement it. One way of dealing with technical debt could gather some information like:


Impacted feature

Mention feature(s) that will get impacted.

Root cause

There could be various reasons for such issues:

  • Infrastructure. For example, a slow server, limited connections supported, etc.
  • Connection to legacy systems which cannot be removed.
  • An issue existed before the Agile transformation.
  • Unclear or too iterative requirements.

Risk if not fixed

  • Tough to maintain and enhance code in future.
  • Unexpected/unreliable behavior of an application.

When risk can occur

  • While adding more code for a new feature.
  • For certain kind of users with specific criteria. For example, a tax report may contain false information on the 1st date of the month.

Time to fix

How much time it may take to fix the issue?


Such a report over a period will be helpful in identifying the cause of the greatest number of technical debt issues and what can be done about it?

What a Product Owner Can Do

The Product Owner can add to the above knowledge so the issue is transparent and understandable to everyone.

How important is the impacted feature

If a feature is a piece of very important functionality and more enhancements are expected, then there is more benefit of fixing the technical debt.

Risk acceptance?

Does the team understand the risk properly? For example, more production incidents.


Such a practice will make issues very transparent and can be prioritized as deemed appropriate.

Overall the idea is to have a common language for the whole team so that they can make an informed decision and make a wonderful product together.

Topics:
agile 2018 ,techincal debt ,scrum ,technical debt elimination ,agile practices ,scrum teams

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}