Bhanu.Golconda

Engineering excellence by effectively handling Technical debt

Blog Post created by Bhanu.Golconda Employee on Nov 24, 2015

´Technical debt is most commonly heard buzz word in agile world and also most challenging to address if it is not properly understood. Projects may get drastically affected because of unplanned Technical debt items popping up now and then. Release plan, schedule and budget may attract reason-less deviation adding more confusion across all stake holders. And metrics such as "velocity" in agile scrum may become an unreliable measure. Most teams knowingly or unknowingly fall in the vicious cycle of technical debt in software development life cycle and it is very important we understand the in and outs of technical debt.

Some examples of Technical debt items:

  • Defects
  • Code refactoring
  • QA Automation
  • Code coverage
  • Automate Build and deployment.
  • Fix the design/architecture, etc.

So what is Technical Debt?

´Technical debt in short, is a metaphor for the accumulated compromise or trade-off between product quality and productivity.

´Just like Monetary debt, technical debt also becomes more expensive in terms of cost and effort as it gets accumulated and grows older day by day.

The good technical debt

´yes, you heard it right! Technical debt is good sometimes, but it can be risky if it is not dealt with caution.

´It is created because of decisions to capture market early and gain timely business value.

´This kind of items are created intentionally with prudent decisions and business people are made aware of the implications of creating it.

´For example:

  • Minor defects
  • Compromising on automation/code coverage although agreed as done criteria.
  • Tweaks to design/architecture to cut short the time to market.
  • cutting down performance, security testing, etc.

The bad Technical Debt

´It is created due to not following engineering practices like Test driven development, pair programming, continuous integration and code refactoring.

  • for example: If we do not refactor code or do pair programming, some maintenance/performance/memory leak issues might slip into a release.

´Most of the times, this kind of technical debt is unintentional because it is created due to engineering team's lack of awareness to best engineering practices and their benefits are not visualised.

 

The ugly Technical debt

´It is created intentionally due to lack of agile values in scrum team like commitment, openness and  courage.

  • Imagine if a team member conveys that everything is Done in sprint review but does not display the openness to acknowledge that some done criteria are not Done. Team members who skip done criteria, tend to accomplish the same in future sprints in background overloading themselves.

 

Sshh.. “Technical Debt Incoming”...

Some conversations in team that signal if we are feeding Technical debt:

  • “Let’s do manual testing”
  • “Code review is not required as this is simple code”
  • “It is just copy and paste of code, no need to refactor.”
  • “Let’s fix this defect later as it is minor one.”
  • “Let’s not change the design now, we can do it next release.”
  • “I think this design works, let us pull this story into sprint.”
  • “We will trigger build this weekend, please make sure to commit your code by end of this week.”
  • “It takes time to set up environment for continuous integration and deployment, let us do it next release.”
  • “We cannot do documentation updates and reviews now, let us do them a week before release.”
  • “We cannot complete user stories if we focus on unit tests, let us do code coverage later”
  • “There are some MINOR open defects, let us not hold release because of them.”
  • “We will start QA automation after first build from developers”

Examples of Technical Debt activities
   

No.Technical Debt ItemProbable solution

1

Defects

pair programming, code refactoring, TDD

Continuous integration

2

Complete pending code coverage

Have Done criteria as 100% unit test coverage. Any deviation need to be agreed

in review meetings

3

Complete pending automation

Have Done criteria as 100% Automation. It is highly difficult to achieve this, but team

can target to achieve this and any deviation can be agreed in review meetings

4

Refactor code

Pair programming/Peer review, Have coding standards agreed with team.

Make team aware of best coding practices.

5

Automate Build and deployment

Have this done in Sprint 0 or early in release.

6

Complete pending Documentation updates

Have strong Done criteria

Other causes of TD:

  • Pressure of release deadlines.
  • Fear of spill overs during sprint.
  • Lack of collaboration between business and engineering team.
  • Lack of knowledge on cause and effects of Technical debt activities.
  • Weak Definition of Done criteria

 

Tips to handle Technical Debt:

1) Business and engineering team need to discuss the benefits in terms of business value and loss in terms of effort/cost before creating any technical debt.

2) Team need to be coached to be more open and courageous in their discussions.

3) As XP's tip - YAGNI("You aint gonna need it"), Not every Technical debt may be needed. So which ever doesn't add value, feel free to agree with all and avoid it ruthlessly.

4) whenever there is an activity which doesn't add direct value to customer, check

  •      Why is it created and does it add value? Update Definition of Done criteria accordingly to address it in future sprints.
  •      Was it foreseen a quarter or six months back, if yes what is the increase in cost/effort now?
  •      If it is created just in time, have this as a learning and if applicable update release planning check-list. For example: Integration testing, performance testing, Security testing, Static code analysis etc. So that we learn and be aware of deviations to release planning.

 

 

 

Hope you liked this article. Please feel free to post your comments.

 

 

~"Millions saw the apple fall, but Newton was the one who asked why." - Bernard Baruch, an American philanthropist.

Outcomes