Get certified - Transform your world of work today

Close

Is Technical Debt Driving You Crazy?

13 July 2017

Shalu Tyagi
@ SpiceJet Ltd.


I'd like to share my experience with our development team, which accumulated technical debt over time while developing new features — in the same way weeds grow unchecked, flourishing under the sunlight and taking water and fertilizers that are meant only for the crop. The development team discovered that they had a huge chunk of technical debt, which resulted in additional unplanned effort, less productivity, unpredictability, and steep fluctuations in velocity.

Just as we need to get rid of the weeds to improve the growth of plants, we must make an effort to reduce technical debt. Here is a summary of what the team did to reduce this load.
 

Our problem with technical debt

The project involved developing a website to automate one of the manual processes in an organization. It was a six-month project with 12 sprints of 15 days each.

Though the teams were well used to the Agile/Scrum framework and followed all ceremonies and best practices religiously, we observed unsatisfactory results in the first few sprints. There was a steep fluctuation in the velocity, and the product quality was decreasing with each sprint. The issue was brought to us, as subject matter experts, for consideration. Because we discovered these results early in the project, we wanted to investigate the underlying cause so that we could implement changes quickly and reap the benefits in the remaining sprints.
 

Identifying the root cause

We uncovered that the team was continuously working on developing new features. At the end of each sprint, delivery was made to the customer for their feedback. By regularly fixing all the critical bugs, the team unknowingly introduced defects into the system. In a rush to deliver new features and functionalities sprint after sprint, fixing these defects became less of a priority. As a result, there was a dramatic difference in what was planned and what was delivered because of the sizable number of defects left in the system. We discovered that the parked defects were damaging product quality and were the root cause of many critical defects that were encountered later. Even though the time to market had been reduced, the overall business objective remained unattainable.

There was obviously a serious need for managing technical debt. We decided to do this by continuously clearing it as we developed new features.
 

Implementing a solution

We suggested the following measures, which resulted in significantly reducing technical debt.
  1. Use the sprint planning meeting as the forum to discuss the quantum of work to be done to accomplish the sprint goal. Create planned work to develop new features and clear technical debt. This also set the right expectation with the customer and added to the team’s motivation, as managing technical debt would not be an overhead any more.
  2. Make technical debt an integral part of the product backlog to ensure that it gets noticed and addressed.
  3. Estimate stories by considering the refactoring when required.
  4. Ensure that continuous integration and automated testing play a vital role. The team wrote an automated test for each defect encountered, reproduced it, and then closed the defect. This practice helped them detect the defect early, if and when it occurred again.
  5. Add automated testing and code coverage to the Definition of Done.
  6. Introduce best coding practices, where the code is properly documented.
  7. Ensure that, wherever possible, the sprint has slack for refactoring.
  8. Introduce automated code review and unit testing tools and initiate pair programming to avoid or address technical debt.
By implementing these practices, the team reduced the technical debt. Their output flourished, just like plants rid of weeds. After technical debt was reduced, the team enjoyed predictability and better productivity.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (5 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe