Technical Debt: FIX IT!

Technical debt: FIX IT!!

I spent several years at home supporting my husband as he climbed up the corporate ladder.  We are a great team. Having been back at work for the past few years, I am amazed at the parallels in practices.

At home, I was able to focus on keeping the home in order, which I now realize is very similar to minimizing technical debt.

As a VersionOne Product Specialist, I am often asked why defects are not automatically tied to a story.  The response that comes to mind is: “Why are you piling up the mail?  Just go through it now, weed out the bills and pay them.  This will avoid a pile of paperwork that will take you hours to deal with later….”

Similarly, why take clothes out of the dryer and leave them in a basket for 5 days?  Now they are wrinkled and you will spend hours ironing (my LEAST favorite task in the world).  If you fold them out of the dryer and place them directly into the drawer or closet, you will spend less time on the overall laundry task.

Sounds simple, doesn’t it? Yet, why do we add defects every time a test fails?  Why don’t we STOP the production line, FIX IT, and move on?

As a product specialist at VersionOne , I am often asked why a defect gets added to the backlog whenever a test fails.  My thought is : “I don’t want to deal with the pile of laundry later.  Just put it away! ”

Agile teams focus on minimizing technical debt by stopping the production line, fixing it and moving on.  (For more info on technical debt:  http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html )

For cases when a defect does need to get added to the backlog, you can always link a defect to a story via the “Breaks Workitems” section of the Details page of the Defect.

Additionally, if an acceptance test fails, and the team realizes more immediate attention is needed, then a blocking issue can be added to that story.  During the daily standup meeting, the team uses the Storyboard view within the TeamRoom to easily see items that need to be fixed prior to the end of the iteration.

Visualization views within VersionOne can provide additional insight into how defects and issues affect other workitems.

In my next blog post, I’ll share some more best practices from our awesome delivery team here at VersionOne.

Gotta run!  The dryer cycle just finished!