Guest post: The IT Manager’s Dilemma with Software Debt

About the Author: Chris Sterling is VP of Engineering at AgileEVM.com, an Agile focused project portfolio and release management tool to support business decision-making in the enterprise. Chris is also a Strategic Agile Management and Technical Consultant, Certified Scrum Trainer, and Innovation Games Facilitator. He is author of the book “Managing Software Debt: Building for Inevitable Change” and helps organizations assess, strategize, and help manage their software debt more effectively.

I first got know Chris when we collaborated to start the very first Seattle Scrum Users Group in 2007 and I’ve been following him ever since. You should check out his blog at http://www.gettingagile.com/.

The team continues to complain about working with that legacy codebase because it has so much debt. That software debt slows them down in feature delivery and they are wondering if we can push for priority to be put into paying it back some?” asked the ScrumMaster. The IT Development Manager looked distraught about the request. She knew that paying back some of the software debt would be a valuable effort but what would the business say about the priorities? “Tell the team that we’ll start paying back some of the software debt starting in the next release. We must get the current release out the door and a change in priorities won’t allow us to get there.” the IT Development Manager said.

Considering the circumstances I cannot tell an IT manager that this approach is not the right way to go. In many cases the IT manager is not in a position to push for technical priorities even when they will provide value to the business. As teams continue to develop on a system without managing the software debt effectively feature delivery throughput decreases. The following picture shows a team’s feature delivery throughput versus time spent stabilizing each release over time:

There are many reasons for this software debt accrual:

  • Pressure of the deadline
  • Inexperienced team members
  • Specialization
  • Over-complication
  • Bad design
  • etc…

IT management has looked for ways to minimize the effects of software debt. We introduce processes that in theory will reduce software debt but in reality seem not to lessen the effects at all. Tools are introduced that will ease the software development process but we still see similar or potentially new mistakes made by team members. Individual team members are asked to specialize in particular software development disciplines such as Database Administrator (DBA), Quality Assurance (QA), or Business Analysis (BA). Although we do each of these specialized roles more efficiently it seems that the product delivered still is accruing software debt. So what do we do?

It is my experience that teams that adopt agile test and engineering practices within an organization that supports collaboration between business units and development teams are more successful in the containment of software debt. These teams tend to minimize software debt and will at the very least deliver with consistent throughput release after release. In some cases I have seen teams accelerate the velocity of their feature delivery throughput over time. The following figure represents the problem IT managers have in deciding to manage software debt effectively on existing legacy software:

A team will have to slow their current feature delivery significantly in order to get consistent throughput over time. I would suggest that managing the software debt effectively would be the best decision for a business relying on this software. Software is a valuable asset for businesses that can:

  • Reduce costs for business processes by automating significant portions
  • Provide information to business quickly so they can make better strategic decisions
  • Attain market share providing shrink-wrapped software to meet the market’s needs
  • Reduce system decay on existing software assets so they can be used into the future
  • and much, much more…

Still, given all of these reasons it is difficult to take on software debt in the wild. We must understand that a typical IT manager has many influences on their decision making, as well:

  • Business pressures for a set of features on a certain date for a set cost (The Iron Triangle)
  • Expectations of feature delivery based on past software releases
  • Unreasonable deadlines due to business issues such as lapsing support contracts and executive management promises
  • Perception of their organization and how that reflects on their capabilities
  • A compensation plan that does not reward managing software assets for future capability
  • etc…

Given all of these circumstances I believe that IT managers are making the best decisions possible. How can we help IT management support our organizational software assets effectively and minimize the effects of software debt? What approaches will allow the software delivery teams to manage software debt while delivering essential features? How can business get more involved and increase understanding of this dilemma that will affect the organization’s capabilities over time? I am interested to hear from anybody who reads this. What are your suggestions?

, , ,

15 comments
a0flj0
a0flj0

IMO it's like with credit cards: continuous debt is expensive. A high debt pushed from sprint to sprint eventually slows down feature addition speed several times. Debt not paid in due time usually pushes you to the software development equivalent of bankruptcy - you need to rewrite from scratch.

I've seen it more than once that managers are oblivious to this process. They trade getting very few features to the market one sprint earlier for getting many more features to the market much later in subsequent sprints, usually for years to come. It may be because I'm a developer, but this doesn't at all make sense to me - you get a tiny gain early on, and pay for it by more than doubling development costs/more than halving feature addition speed for a long time afterwards (in extreme cases).

The only thing that can be done about it is to make costs visible. If you want managers to understand what you're saying you have to speak their language. It's one thing to keep up a constant velocity - constant speed makes managers happy, even if they don't understand what it means. It's something completely different to tell management the interest rate you pay for technical debt is 60% and rising - i.e. they waste 60% of the available resources. Having a record of a manager wasting 60% of available resources sprint after sprint will make it the manager's problem to reduce technical debt, instead of just the development team's. Also, similarly to accounting, it wouldn't be the manager's business to interfere with technical debt interest rate estimation, just the development team's.


PierG
PierG

Well, I would expect also some solutions from the paper, not just questions :) At least something more than "It is my experience that teams that [..."do agile"...] are more successful in the containment of software deb" :) PierG

(c) Scrumology Pty Ltd.

Read previous post:
Chris Sterling
Guest post: Managing Software Debt

Managing Software Debt Continued Delivery of High Values as Systems Age Many software developers have to deal with legacy code...

Close