Archive for March, 2011

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.

What could we learn from Cricket?

March 26, 2011

I mean, Cricket – the game that is played in most of the major countries of the world.

We had our “Agile Hyderabad” group meeting yesterday. We spent most of the time discussing about testing challenges. Most of the companies those follow agile software development has the problem of developers and testers keep “We and They” attitude.

While I was watching cricket, as we are fully into the World cup fever, it struck me that there are few things we could learn from the cricket teams. A cricket team has “Batsmen” and “Bowlers”. However, if it is required, a bowler (supposedly “none to less” experienced in batting) is expected to make few runs. Same way if the regular bowlers are not making an impact, the captain decides to use any bowling skills of the batsmen. The goal is to win the match and every member of the team strives for it.


The goal of an agile team is to deliver the quality software at the end of the iteration. The team has to figure out who does what, but the goal is to deliver the stories. Some team members would have the specialized skills like programming or testing, but they should be willing to do other activities outside their specialization also. This could be a developer performing some testing or tester fixing bugs or architect writing documentation or what ever. Agile teams need to redefine their roles and develop “We are all in this” attitude.

Moving on to a different topic, when I talk about agile way of developing software, it is big change to lot of people from how they have been building software.  People say  – “ We have been doing it for ages. Why do we do it in different way now?” Do we have to follow something just because we have been following it forever?

Long time ago when I was small, a cricket match always started with a pace bowler starting the bowling session with a new ball. It has been well established for decades that a pace bowler could make a new ball to swing and get some early wickets. To my surprise, a spin bowler started bowling session when India played against Australia in the world cup 2011. The reason why the captain took that strategy is because they don’t have enough good pace bowlers and they have very good spinners. Besides, Australia is not very good at playing spin bowling. Indian team ditched the conventional practices and implemented the practice what goes with the current situation. As a whole the team did a great job and India won the match against the odds.


In the current market conditions, the stakeholders of a software project expect that the time-to-market should be reduced to beat the competition. Organizations want to be adaptive to the market requirements. To achieve today’s market needs, an organization needs to implement the practices those work for the current conditions. Change is hard, but it is inevitable.

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 http://www.sei.cmu.edu/architecture/tools/hardchoices/ . 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.

 

My First Blog

March 25, 2011

I wanted to write blogs ever since they were invented. Enough of procrastination…

Finally, I am determined to start writing at least before my son starts writing one. I am going to write more on ‘Agile Software Development’ and hopefully other stuff too.