Scrum & Technical Debt: Love the One You’re With

Posted By Jonathan Bloom on September 12, 2011 | Technical Debt

Bravo to Joe Little, who writes the Agile & Business blog.

Little recently penned a piece about the intersection of Scrum and technical debt titled “Scrum Hates Technical Debt.” I’m sure it does, but I think what he really means is that true Scrum hates technical debt.

Little very accurately points out that much of what passes for Scrum in today’s development world is little more than “the bosses” pushing software development through at the risk of software quality. As he sadly but correctly points out:

People are doing Scrum in an unprofessional way, and then are unhappy about it. And often want to blame Scrum.

As he further explains, Scrum is usually not the culprit in the building of technical debt and therefore does not deserve the bad rap it gets. The problem as he sees it is similar to my take on it. He says:

We engineers have to stop ‘going along’ when the business guys say ‘you have to skip that stuff and just get more features out the door’.  We have to explain to them (and, to be fair to them, they don’t know the facts) how we are only hurting ourselves (the firm, say) and the customers by ‘going too fast’.  We have to explain it many times.

Down and Confused

This is where I applaud Little. He is quite right that Scrum users need to resist when pushed to “just get it out the door.” It doesn’t matter what you are building – application software, houses, cars or picture frames – just getting it out the door results in problems with structural quality.

But it does more than that. While the structural quality may be a short-term issue, in the long term this “just get it done” attitude cultivates a fatalistic view among developers. If you pound into developers that the only thing that is important in creating software is getting it out the door, they will carry that languor and defeatist attitude throughout their careers…and will continue creating software as if quality doesn’t matter.

Little’s lament that this is a difficult problem to overcome and that in the end it is a problem that can only be solved by people, not by any tool or technique, is a very valid one. Overcoming technical debt in a Scrum-based setting has as much, if not more to do with overcoming a mindset of speed over quality at all costs as it does with any of the IDEs or testing tools used in the creation of the software.

What this all amounts to, though, is that the people on the business end need to be made to understand what’s at stake. While Little says “Scrum Hates Technical Debt,” though, it is through technical debt – or rather the monetizing of it – that developers can best get their message across.

A Rose in the Fisted Glove

Little, in his blog, defines technical debt as, “All the things that we did or did not do, that are “in” our current product, that make it hard for us to change it quickly.”

While there is truth to that, it falls a bit short of the full implications of technical debt. As I’ve said in previous blogs, we have identified technical debt as the cost to fix the structural quality problems in an application that, if left unfixed, put the business at serious risk.

So more than representing “bad stuff,” this means technical debt also reveals where IT Departments and Business Owners can find common ground on which to discuss technology needs. By monetizing technical debt and revealing the true cost of risking failure, IT departments can demonstrate how much it costs to do something the “good enough” way versus “the right way.”

Assessing structural quality through a platform such as automated analysis and measurement, a company is able to calculate the number of density violations in the source code before deploying an application. This is done by taking into consideration the number of violations, their severity, the number of hours it costs to fix these violations and the average hourly cost of software developers’ time.

The result of this calculation provides an IT department with a dollar figure it can show to corporate management as concrete evidence of the need to address issues before they are deployed. And since money is the international language of love for business, Scrum should learn not to hate technical debt, but rather embrace it.

Tags: Agile, Application Quality, automated analysis and measurement, Project Management, SCRUM, software analysis, Software Development, software measurement, Software Quality, structural quality, Technical debt