The Agile Executive

Making Agile Work

How to Break the Vicious Cycle of Technical Debt

with 10 comments

The dire consequences of the pressure to quickly deliver more functions and features to the market have been described in detail in various posts in this blog (see, for example, Toxic Code). Relentless pressure forces the development team to take technical debt. The very same pressure stands in the way of paying back the debt in a timely manner. The accrued technical debt reduces the velocity of the development team. Reduced development velocity leads to increased pressure to deliver, which leads to taking additional technical debt, which… It is a vicious cycle that is extremely difficult to break.

Figure 1: The Vicious Cycle of Technical Debt

The post Using Credit Limits to Constrain “Development on Margin” proposed a way of coping with the vicious cycle of technical debt – placing a limit on the amount of technical debt a development team is allowed to accrue. Such a limit addresses the demand side of the software development process. Once a team reaches the pre-determined technical debt limit (such as $3 per line of code) it cannot continue piling on new functions and features. It must attend to reducing the technical debt.

A complementary measure can be applied to the supply side of the software development process. For example, one can dynamically augment the team by drawing upon on-demand testing. uTest‘s recent announcement about securing Series C financing explains the rationale for the on-demand paradigm:

“The whole ‘appification’ of software platforms, whether it’s for social platforms like Facebook or mobile platforms like the iPhone or Android or Palm, or even just Web apps, creates a dramatically more complex user-testing matrix for software publishers, which could mean media companies, retailers, enterprise software companies,” says Wienbar. “Anybody who has to interact with consumers needs a service to help with that testing. You can’t cover that whole matrix with your in-house test team.”

Likewise, on-demand development can augment the development team whenever the capacity of the in-house team is insufficient to satisfy demand. IMHO it is only a matter of little time till marketplaces for on-demand development will evolve. All the necessary ‘ingredients’ for so doing – Agile, Cloud, Mobile and Social – are readily available. It is merely a matter of putting them together to offer on-demand development as a commercial service.

Whether you do on-demand testing, on-demand development or both, you will soon be able to address the supply side of software development in a flexible and cost-effective manner. Between curtailing demand through technical debt limits and expanding supply through on-demand testing/development, you will be better able to cope with the relentless pressure to deliver more and quicker than the capacity of your team allows.

10 Responses

Subscribe to comments with RSS.

  1. I’m sceptical that “it is only a matter of little time till marketplaces for on-demand development will evolve”. I may be misunderstanding what you mean by this, but it implies a vision whereby developers can be “elastically” dropped into a team to increase capacity at short notice, for short periods of time.

    Agile certainly doesn’t bust the “Mythical man-month”, far from it. That can’t really be what you meant?!


    September 20, 2010 at 8:52 am

    • I would say it is not “only” developers. I envision marketplaces for various kinds of knowledge work – e.g. development, marketing, professional services. We are just about at the point where such marketplaces are becoming granular: it is not about a marketplace in which job offers are posted, it is a marketplace in which tasks are posted. The boundary of the firm becomes much more elastic than it used to be. See The Firm, the Market and the Law for an explanation how change in relative costs shifts the boundary of the firm.

      As to the mythical man-month, Michael Mah‘s 2008 study of Agile teams – How Agile Projects Measure Up, and What This Means to You – showed that mythical man-month effects might not apply to Agile teams. Various methodical advances in Agile over the past two years are quite consistent with Michael’s findings.




      September 20, 2010 at 10:25 am

    • Please see as well today’s post in FastCompany on the Shapeway operated market place. To quote from the article:

      Shapeways also operates an Etsy-style marketplace that allows people to hawk their work in online shops — a boon to independent designers who’d normally have to cozy up to a mainstream manufacturer to bring anything to market. Shapeways’s output has grown from 600 products a week, to 2,500 in less than two years; that’s allowed them to drop prices to a third of what they were in 2008. And it’s still growing.




      September 23, 2010 at 8:11 am

  2. Lee –
    Nice post! In the spirit of empowering the team, we encourage them to use Innovation Games® online to both identify technical debt and to prioritize the debt that is most important to fix. The process works especially well in distributed teams, and the management team can control how much money is spent in fixing technical debt vs taking on new features by managing the amount of currency provided to the players.

    A full description of this is here:


    Luke Hohmann
    CEO, The Innovation Games® Company
    821 W. El Camino Real
    Mountain View, CA 94040 The seriously fun way to do serious work — seriously.
    Follow me on twitter at lukehohmann

    Luke Hohmann

    September 20, 2010 at 9:34 am

    • We are independently seeing the same picture, Luke. The combination of Social/Community and Serious Games is very powerful. I would not like to speak for Forrester’s Tom Grant or Dave West, but my guess would be they will have a lot to say on the subject…




      September 20, 2010 at 10:48 am

  3. I’m having trouble pairing reducing technical debt with outsourcing development. In my experience, since external developers often don’t maintain the code they write, they don’t have incentives to write code that is low in technical debt, though I’m the first to admit that my experience isn’t conclusive.

    Amy Thorne

    September 21, 2010 at 8:17 am

    • Amy, you can use technical debt to change the behavior of external developers. For example, put a stipulation in the contract on the amount of technical debt as part of your code acceptance criteria.




      September 21, 2010 at 9:02 am

  4. […] in the government sector compared to the private sector. As pointed out by Amy Thorne in a recent comment posted in The Agile Executive, it might also be attributable to the incentive […]

  5. […] The Code2Cloud announcement is primarily about the {Agile –> Cloud} link in Figure 2. The {Cloud –> Mobile}, {Mobile –> Social} and {Social –> Agile} are just as powerful. For example, the {Social –> Agile} link, in conjunction with Cloud and Mobile, opens the door for highly efficient Testing as a Service. […]

  6. ‘placing a limit on the amount of technical debt a development team is allowed to accrue’ –> you assume here that people actually care about debt? Or, that they are aware of it? Most people are not.

    The other thing, some people think debt is a good thing, a way to leverage.

    Think of Steve’s explanation:

    And mine in relation to ignorance:


    November 22, 2010 at 6:36 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: