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

by

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.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Jonathan Bloom Writer, Blogger & PR Consultant
Jonathan is an experienced writer with over 20 years writing about the Technology industry. Jon has written more than 750 journal and magazine articles, blogs and other materials that have been published throughout the U.S. and Canada. He has expertise in a wide range of subjects within the IT industry including software development, enterprise software, mobile, database, security, BI, SaaS/Cloud, Health Care IT and Sustainable Technology. In his free time, Jon enjoys attending sporting events, cooking, studying American history and listening to Bruce Springsteen music.
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|