Agile Pitfall #2: Too Much Technical Debt

Let’s face it, Agile has some tremendous benefits.  If you are practicing agile at your company, you know that firsthand.  Agile also has some pitfalls that can be extremely deadly if they are not addressed properly.  Most of us have learned how to avoid them by implementing costly mistakes.

Agile Pitfall #1: Lack of Integrated Software Testing

Agile Pitfall #2: Too Much Technical Debt

Agile Pitfall #3: Agile Team Silos

Agile Pitfall #4: Too Focused on Agile Team Roles

Agile Pitfall #5: Folks, It Isn’t All About Velocity!

Sure there are other things that agile has issues with, but we will cover those in subsequent agile posts.

Using the agile methodology, software can be developed very quickly, in fact, business needs demand it is produced as quick as possible.  While there is nothing inherently wrong with that, it is important to develop it efficiently.  Agile teams want to build the best designed and highest quality product possible.  However, that isn’t always what happens.  My team has recently been involved in leveraging a COTS product called Globalscape to consolidate all our B2B file transfer systems into a single solution.  In fact, our company was acquired, so between both legacy companies we had four solutions which were being used.  We selected Globalscape, but the product was brand new to our team.  We didn’t have extensive experience but were driven to move off the other systems.  We made the best decisions that we knew at the time, but looking back, there were some things that if we had better information and experience with the product, we would have certainly done differently.  Naturally, we accumulated technical debt, and we created stories in our backlog to handle those.  In certain sprints, we had to put more technical stories in place to implement the necessary changes.  While our business partners weren’t thrilled, they understood those needed to be done.

In some situations, you can address technical debt issues as you are addressing stories in the backlog.  For example, with our file transfer product, we created a generic function to address how email notifications were delivered, which was much more efficient.  While we were moving other B2B files into the new platform, we would go ahead and make those changes, so that we would not have to revert and make those technical debt changes later.

It is also a good idea to keep 5 to 10 percent of your sprint capacity available to handle technical debt issues.  If you have one story per sprint handling technical debt, then it will make it a lot easier in not having to deal with too much technical debt later.

Hopefully this real world example will help you avoid Agile Pitfall #2: Too Much Technical Debt!