Software development projects that have a large amount of software debt are at risk for poor quality and missed...
schedules. Agile expert Chris Sterling explains software debt in his new book, Managing Software Debt: Building for Inevitable Change. In part one of this two-part interview, he describes the types of software debt and provides helpful advice of how it can best be addressed in Agile environments.
SSQ: Can you start by giving us a brief definition of “software debt”?
Chris Sterling: Software debt is a term that was created to define those aspects in software that slow down future delivery to its intended users. Technical debt is commonly used but I thought that this type of software debt focused mainly on the programming aspects of software development. Software debt goes beyond technical debt and encompasses other aspects of software development that also contribute to delaying future delivery of valuable software. Each type of software debt can be monitored with different tools and approached effectively with different methods. Therefore, teams, management, and organizations can develop more specific strategies for managing their own software debt for each specific type.
SSQ: Your book opens by describing five types of software debt: technical, quality, configuration management, design and platform experience. We seem to hear the most about technical debt. Is that the type of debt that’s most prevalent? Is it the riskiest if not addressed?
Sterling: Yes, technical debt was a term coined by Ward Cunningham on the c2.com wiki many years ago that seemed to initiate this discussion around “debt” as a metaphor for things we do today that will have negative effects on our software delivery in the future. I don’t see technical debt as the most prevalent or the most risky of the software debt types. Each type of software debt is potentially risky if ineffectively managed. If we think of software as a business asset that potentially provides value, we can also see how software debt can lead to increased maintenance costs, delay, and ultimately a liability for the business that owns it, either the creator or customer of that software. Managing all types of software debt sufficiently leads to maintainable, changeable, and ultimately more valuable software assets for businesses that own them.
SSQ: Is software debt a concept only used when developing in Agile environments? Can it be applied to projects that are using traditional software development methodologies?
Sterling: It is my opinion that most of the methods, practices, tools and heuristics discussed in the book are not only for teams that use a formal Agile method. Managing software debt can be applied to any software development effort. Scrum, extreme programming (XP), and other Agile methods lend themselves to more frequent feedback loops and adaptation than most methods but there is nothing stopping an organization that follows phase gate processes from applying aspects of managing software debt from the book. It can be more difficult because of the amount of involvement and buy-in that the organization will need to apply some of the techniques but there is always room for improvement whether you’re involved in heavy phase gate processes or using Agile methods such as Scrum. We just have to start improving and therefore, try something.
SSQ: You mention one way of handling technical debt is to add it to the product backlog. In this case, do user stories get written? Does the product owner have a say in prioritizing these items?
Sterling: A main principle in managing software debt is to “maintain one list of work.” This allows those advocating for the business to ensure that priorities are based on business goals and objectives. When teams pick work from multiple sources, such as bug databases and technical improvement ideas, priorities are not transparent to business. Therefore it is imperative that whatever needs must be addressed, either what we call technical debt or other risks to our software and its associated infrastructure, are put into this single list to apply business priorities to it. This is sometimes scary for software development management and teams to buy into since history has shown that technical items tend to get demoted. It has been my experience much of the time that technical folks are not able to help the business understand the value of these technical items.
Over the years, I have been quite successful in getting technical items prioritized appropriately with business folks. I attribute this to a few different methods that I have picked up through the years:
- Abuse Stories -- This I picked up during a session that Mike Cohn was presenting on user stories. It involves writing user stories from the point of view of a potential abuser of your software. An example might be: “As a Malicious Hacker I want to steal credit card information so I can make fraudulent charges.” The value is described in terms of the “cost of not addressing it.” This type of value can be applied to many technical items that have to do with software quality attributes such as security, usability, and performance.
- Software Quality Attributes Rating Tool -- A tool that was inspired by work at SEI. The software quality attributes rating tool is a spreadsheet that can be used to identify what are the most important quality attributes from a technical and business perspective. We usually have a development team and project stakeholders fill it out separately by choosing their three most important. Then we have them come together and choose the top three or so that should be a focus in the software delivery as crosscutting concerns.
- Collaboration -- Working closely with the Product Owner, customer(s), and project stakeholders can also be effective at getting technical items prioritized appropriately.
The book goes into much more detail about these and also provides additional context.
SSQ: Can technical debt be avoided by having a more thorough “definition of done” for each story?
Sterling: I do not believe that we can avoid any type of software debt completely. Humans create software, and we sometimes don’t make perfect decisions. A team that asserts their quality criteria as a team for each story that is delivered and thought to be done reduces the amount of software debt for the aspects covered. By having a more thorough “definition of done,” the team’s asserted quality criteria for each iteration, we cover more aspects of the software delivery and therefore continue to reduce the risk. On many projects, and in our current software development on AgileEVM, we had “push-button release” capabilities at the end of every iteration and even used multiple times per iteration or every day depending on the application’s environment and user context. This meant that we could run a single script, usually named “deploy,” that pushes a new application version to production. We practiced running this script, along with its counterpart “rollback,” multiple times per iteration so that deployment became almost a non-event. And it was now up to the business to decide if the accepted features were ready to be shipped to users or not. Teams that have this capability are able to create potentially shippable software increments at least every iteration and maybe even more often if it is desirable for the business. This continuous delivery of software to users drives additional reduction of software debt accumulation in my experience.
Chris Sterling is author of the book, 'Managing Software Debt: Building for Inevitable Change', published by Addison-Wesley Professional, Dec.2010, ISBN 0321554132, Copyright 2011 Pearson Education, Inc. Chris is a Partner at Sterling Barton LLC, where he works with clients as a technology, management, and Agile consultant. He has an extensive technology, process, and consulting background allowing him to work with a diverse set of clients and teams. In addition to consulting, he is a Certified Scrum Trainer and Innovation Games Facilitator. He also teaches the Advanced Topics in Agile Software Development course at the University of Washington for the Agile Developer Certificate extension program. For more information on the book, and a sample chapter, Chp#4, "Executable Design," please visit the publisher site "Sample Content" tab below the book image.