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. You can take the help of experienced lawyers to defend against wage garnishment and know about other debt issues.
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.
I was watching a Gordon Ramsay show where the celebrity chef goes around restaurants helping them to become better at what they do.
I recall a discussion about when to clean your kitchen work surfaces. You clean as you go — otherwise there’s always a heightened risk of giving your customers food poisoning. Also, if a pot spills its contents and needs to be cleaned up in a hurry, it’s much easier to do that big clean up when it was spilled onto an otherwise clean work area.
Also, kitchens are cleaned at the end of the shift before staff leave for the night. Of course, this is a quick clean if the team has been cleaning as they go during the shift.
It’s also important staff of kitchens do a weekly check to make sure nothing in the regular cleanup has been forgotten. Look through the fridge for expired products, check under appliances to make sure nothing has slipped underneath, make sure knives are sharp, etc.
All of this comes down to the question “what is the culture of your kitchen?”
That is a good way to take care of some of the debt. We do that too when ever it is possible. I haven’t read your book and wish to read it as soon as I can.
Totally agree that we will all create some debt in the wake of our changes. I can see how this could be a good tactic. Teams I have worked on and with as a consultant have also used tools such as Sonar (http://www.sonarsource.org/) to monitor technical debt for early warning signs. Also, when we get a new item to deliver from the PO we will sometimes check on Sonar and drill down into the code we might be contacting to see if there is debt to be worked on there. Not on every item but we can usually tell which ones are potentially interesting from a technical debt perspective.
BTW. Have you read my book Managing Software Debt? It discusses this and more beyond technical debt into other aspects of software development. Would be interested in your feedback.
Thanks, Chris.
I suggest the same thing as you do that the team takes care of the debt in the regular sprint itself.
However, what we realized is that how much ever perfect you are, there will be some debt. What seems to be a good solution doesn’t seem that way later. So, team usually have better understanding of the debt in retrospect.
About the slowness, I didn’t mean it that way. When I talk to PO, I say that the work done a certain period is same i.e. let us say work done in 6 months is same whether we do with or without a tech debt sprint. However, having an exclusive technical debt sprint would give a better out come since the team would have better understanding of the debt.
About the game, if you move the bridges closer to where the path is taking ‘U’ turn and play my rules you will see the difference clearly.
@Nanda, I really like the game. Can’t wait to play this in training classes and see how it works with teams and management.
In my experience, it is always better to manage technical within each iteration rather than during a specific iteration. We use abuse user stories, put into estimates, static code analysis data, and pair programming along with ruthless refactoring inside TDD to support this. It is my opinion, backed up with some evidence/data and anecdotes, that this does not lead to slowing down but rather speeds up delivery. Some teams I have worked with on that inherited legacy code were able to increase delivery throughput using these techniques by 6-10X without technical debt focused iterations.
I am interested in any data you might have about teams slowing down when doing refactoring and if you could find the root cause to this slowness. Is it actually tending to the technical debt or is it because of approach/discipline/experience?
Thank you for a thought provoking article and a great game that I can’t wait to play!
Chris Sterling
VP of Engineering
AgileEVM Inc.
** Where Agile Meets Business **
Got it, Nanda. Thanks for clarifying.
Manoj,
Generally there is a risk of people postponing the work to technical debt sprint. Technical debt is something in addition to ruthless re-factoring. Remember that you get very little time for this sprint (2 weeks in 6 months like that). So, the deb t you are leaving for this sprint should be very minimal.
Nice suggestion, Nanda. I have one doubt/apprehension about this approach which I would like to clarify. If we are aware that there is a 2weeks, or so, technical debt cycle then aren’t we at risk of procastinate some of the stuff which should be handled during sprint only?