The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

21st
NOV

Technical Debt – The High Cost of Change

Posted by admin under Scrum Basics, Scrum Discussion, Scrum Transitions

My consultants and indeed my own software development teams often grapple with technical debt. often Products carry technical debt when they are difficult or risky to change. Technical debt isn’t listed on your balance sheet, yet it can destroy your business.  It’s important to understand where Tech Debt comes from in order to effectively address it:

  • A common reason for bringing technical debt into a code base comes from the business stakeholders. Assuming they have a reasonable understanding of the consequences, the business might consider getting something released sooner is of more value than avoiding technical debt. They should understand the “interest” payment that will be incurred if they insist on this path! In many cases, businesses stakeholders simply don’t understand the ramifications of what they are asking for, nor do they fully grasp the concept of. They make decisions solely on immediate business pressures rather than taking a more long-term view.
  • Technical debt also comes in the form of poorly constructed, inflexible software. This may come about when functions or interfaces are hard-coded, and as such, are difficult to change.
  • Lack of documentation is another reason for technical debt, both in the code itself and in the external documentation. When documentation is poor, new team members who want to modify the code in the future have a hard time coming up to speed on the code which that slows development.

Enlightened management can have a real impact on mitigating the addition of technical debt and in paying it down as you go, by constant refactoring. There is an interesting webinar on this topic available here.

Be Sociable, Share!
Comments Feed

Reader's Comments

  1. Thomas Cagley | November 23rd, 2011 at 2:19 am

    We talk a lot about the causes but not whether there is a responsibility that attaches when we participate in the creation of technical debt. Does it really require an enlightened management or do we have an obligation to refactor?

    Tom Cagley
    Editor – Software Process and Measurement Cast

  2. admin | November 28th, 2011 at 9:55 am

    Yes, it requires enlightened self management. In my opinion, you’ve got to have enlightened management to foster the self-managed obligation for re-factoring and other tedious practices. The alternative is that management could impose the requirement to refactor as a story for each sprint, but that smells pretty waterfall-ish to me.

  3. Raja Nagendra Kumar | December 7th, 2011 at 11:43 pm

    Lack of Clean Code is the root cause of many project failures, exploded costs and huge post release bug count.. TejaSoft is into code re-engineering since last 10 years.. however, we see even the enterprises are not ready for fixing it unless it is a last mile or top boss chair is at risk.. At TejaSoft IT Waste and IT Rework is considered as crime..

    We believe clean code engineering needs a big advt to help top management to understand its importance, value and to fit in a process for avoiding or to handle it at every stage.

    In our recent code audit to one of the world number one, portal and embedded software vendor.. shows that as much as 35% code was crap and was eating the time of almost 50 of their engineers..

    In this regard, could you pl. share some process changes which are happening in IT.. to get this done right (accountability right).. specially in the context of US enterprises and start-ups pl..

    Most of them talk about re-factoring, unit testing and great team.. however none of them gets reflected in reality (inside the code)..

    Though ebay seems to have realized the problem, I still not sure.. if they really want to fix it at war speed..

    Regards,
    Raja Nagendra Kumar,
    C.T.O
    http://www.tejasoft.com
    -Factor 4 Benefits : Halve the Efforts, Double the Results

  4. Wilbur | June 1st, 2012 at 11:48 am

    I would have really appreciated a definition for Tech Debt somewhere in this article.

  5. admin | November 30th, 2012 at 6:34 pm

    Hi Wilbur – here’s a link to an article that explains technical debt: http://www.danube.com/system/files/CollabNet_WP_Technical_Debt_041910.pdf

Leave a Reply

| Scrum Methodology | Scrum Training | Scrum Software | Scrum Tools | Scrum Master Certification | About Us |