Agile Australia 2011 Series - Tackling Technical Debt

I love the topic of technical debt on agile projects and how it’s the cause of much debate and discussion. It seems destined to trip project managers up and cause massive amounts of project manager stress . I think the angst is around the seemingly unpredictable nature of technical debt, and how it has the potential to result in project blow outs, and how unsettling that can feel when we have faith that agile projects will bring us efficiency and yes, predictability. Maybe if technical debt didn’t exist Agile would really be the silver bullet that everyone seems to be looking for, or insisting that Agile isn’t!

When I was a project manager on agile projects it used to drive me crazy whenever my team doubled their story points in an iteration by finding tech debt here there and everywhere that they stated MUST be attended to. It’s really hard to contradict developers on this topic, they make a compelling case for tackling debt that will slow you down the more you want to extend your software platform in the future. The trouble is most software projects focus on the here and now and consequently decisions that are focussed on the project delivery date, right in front of our noses, get made.

Martin Fowler has penned a great hypothesis on ‘design stamina’ and represents graphically the time at which short term decisions might pay off against where they cost you more due to the increased effort to build more features in a world where you made only short term design decisions.

My team wouldn’t have forgiven me if I had not talked about tech debt at Agile Australia as it’s a hot topic there at the moment. So without dwelling I’ll tell you what we do, and what I think you could do for getting debt relief in this area:

• Tame the debt! Respect the cost – by this I mean yes include debt cards, include refactoring but respect the business value you are delivering at the time and don’t go crazy with it.
• Tackle debt outside the project with a quadrant – Create a Tech Debt wall with a quadrant, include effort and payoff axis and post tech debt cards on the quadrant. Empower people to foster some debt cards on their project. Even creating the tech debt wall provides an outlet for frustration. Perhaps do some blitzing on rainy days or quite periods (intersprint breaks) or devote some budget to it. Perhaps some money you saved by chucking something out can be spent towards paying down debt?

• Don’t keep it a secret from the customer or bury your head in the sand. Make it visible to them, staple your relevant tech debt story cards to the businesses story cards if needs be. If you can articulate the benefits to addressing tech debt you might be surprised how they are willing to prioritise it along with functional scope. If you can articulate it well enough, it may seem ludicrous not to include it as scope.

• Don’t make the mistake of thinking it’s an IT problem and IT need to deal with it. Describe it in business value terms. If the business cannot understand it they will never prioritise it as important to do.

These are my high level approaches to recognising and addressing technical debt.

There’s a whole other science around the prevention of the contribution to the tech debt. Factors like very skilled developers and all of the great XP development practices we know about come in to play here. That’s a great big topic and also a reason why I mapped this topic in my 'hard and expensive' quadrant during my Agile Australia presentation. I personally wouldn’t recommend on day 1 you start your agile transformation with the identification and eradication of technical debt but you certainly shouldn’t kid yourself into thinking you will never have to deal with it. The truth is you are already dealing with it in the cost you are paying for your software today.