Archive for the ‘Technical Debt’ Category

What should you do in “Technical Debt” sprint anyway?

March 28, 2011

Now that you convinced your product owner to allow you to have technical debt sprint, what should you do in those anyways?  Let us get into product owner’s shoes and think what to expect from and after the technical debt sprint. Product owner wants the team to build stories with a higher velocity or at least sustain the velocity. So, what kind of activities the team should do in the technical debt sprints to achieve this goal.

Some of the areas I see as candidates for this sprint. Are:

Code cleanup:

You might have left some unused code in the system or an unused database column is still lying around or you really want to re-factor some code that is bothering you. I am sure you could come up with a long list of these pain points, which would come in your way any time you are working in that area.

Same rules apply to testing debt also. This could include reorganizing the tests, remove unused tests and any test changes associated with code changes. The goal is that the most of these pain points are gone and the code looks cleaner and maintainable at the end of the technical debt sprint.

My team is in a technical debt sprint currently and some of the items they chose to work on are:

  1. Re-factor enums to have consistent lookup() method. In some enums it spelled as lookUp().
  2. Delete unused legacy code. We weren’t sure before if that is being used some where due to lack of automated tests.
  3. Remove the last piece of legacy code from a module. This required some coding in the new code base, however allowed us to removes 1000 lines of code.
  4. Re-factor certain areas of acceptance and web tests.
  5. Remove a database column from the table.
  6. Rename a database column in several tables for consistency.

Software upgrades:

These sprints are very well suitable for upgrading your third party software. This will allow you to start using the latest and greatest features of that software. On the other hand if you don’t upgrade the software for too long, the version you are using may not be supported any more. You need to make sure that all the dependent software is upgraded together which could require significant time.

Build features those reduce supporting activities.

The time spent in supporting activities basically not used for any features development. This supporting activity could be anything that requires your time, depending on your current situation. If you build a little features that will reduce the support time, that would be a great thing to work on in these sprints. This will allow you to spend more time on new development and will improve the velocity. Some of the tasks my team is looking at in the current technical debt sprint are:

  1. There is a long running process that doesn’t send any “Completed Notification” to users. Every time user needs to ask the engineers about the status of the process. Engineers are adding a feature to send an email to users at the completion of the process.
  2. Recently some reports were taking way longer to show up and causing production support tickets. Engineers picked up those reports to tune.

You need to be careful in picking up these tasks, since some of them could be very big and could take up the whole sprint. Team needs to look at the ROI on each task they are going to work on.

Do you have enough time?

Now you know what are the various things to work on. But your time is limited and how do you make sure that you will get maximum ROI?  There will be few mandatory tasks those you have to address in this sprint.  This could be upgrading a third party software which you delayed enough that you can’t delay it any more etc.

For the rest of the tasks, consider the following aspects:

Utility or Value : How valuable is fixing some thing would be? The fix could affect only one area of the system. This could be useful but the value is limited since that will help the future development/maintenance in that part of the system only. On the other hand, if the fix is going to be in a framework which is used through out the system, the benefit would be lot more.

Effort : Another aspect is how easy or hard to perform the task. Some tasks might take few hours while others might take the whole sprint. You need to be smart in choosing what you want to work on. My general guideline is to work in the following sequence, which is the combination of the two aspects mentioned.

  1. Easy and High Value.
  2. Hard and High Value.
  3. Easy and Low Value.
  4. Hard and Low value.

Why agile teams need “Technical Debt” sprints?

March 25, 2011

Lot of people asked me why do they need “Technical Debt” sprints. In my experience lot of product owners don’t see value in these sprints. I would like to make an attempt to answer that question.

Technical debt is the unfinished work due to the short cuts taken by the team to deliver a story faster. This could be due to an impending deadline or under estimated effort or what ever. It is necessary for the team to periodically clean up that code before it gets unmanageable. Some one asked me that if the team is doing a ruthless re-factoring as one of their practices, why do they need technical debt sprints? Though the team is disciplined, it is not possible all the time to re-factor, for several reasons. For example, if there is lot of legacy code with no tests around it, it would be hard to change that code.

Besides all the reasons said above, in my opinion it is a strategy how the team wants to work. The work done in a quarter or six months is going to be same whether 1) the team doesn’t leave any debt, in which case they work slowly or 2) leave some technical debt and take care of it at the end (of quarter or six months). IMO, the later choice would lead to a better outcome since the team would have a better understanding of the debt. So, I always recommend a periodic technical debt sprint in addition to continuous re-factoring.

I recently came across a game that explains technical debt and results of not paying it back. This game is designed by Software Engineering institute (SEI) and called “Hard Choices”. Read about the original game at . Basically the game has the aspects of taking shortcuts (creating debt) and paying it back (losing a turn). If you don’t pay it back, it will slow you down.

I actually played it differently. I have three players and they move with the same roll of dice. However, there are rules for each player:

Player 1: Always takes the shortcut, but never pays back.

Player 2: Always takes the shortcut, buts pays back right away (by losing the turn).

Player 3: Never takes short cut.

At the end, player 2 won as I expected. Player 1 and 3 reached the end almost at the same time.

I looked at the board carefully and figured out that if I change the positions of the bridges, I could make it event clear on how player 1 is going to suffer at the end. In this case, even player 3 is likely to reach the end ahead of player 1.

In summary, technical debt sprints are very much required to keep the backyard clean. This will at least allow the team to maintain the velocity, if not there is a big improvement.