While agile methods have become popular in commercial software development organizations, the engineering disciplines needed to apply agility to mission-critical, software-reliant systems are not as well defined or practiced. To help bridge this gap, the SEI recently hosted the Agile Research Forum. The event brought together researchers and practitioners from around the world to discuss when and how to best apply agile methods in mission-critical environments found in government and many industries. This blog posting, the third installment in a multi-part series highlighting research presented during the forum, summarizes a presentation made during the forum by Ipek Ozkaya, a principal researcher at the SEI, who discussed the use of agile architecture practices to manage strategic, intentional technical debt.

Ipek's Talk on Strategic Management of Technical Debt

In her opening comments to the audience, Ozkaya established that two decades ago Ward Cunningham coined the "technical debt" metaphor, which refers to the degraded quality resulting from overly hasty delivery of software capabilities to users. Cunningham stated that shipping code quickly is like going into debt. A little debt speeds up development, and can be beneficial as long as the debt is paid back promptly with a rewrite that reduces complexity and streamlines future enhancements. A delicate balance is needed between the desire to release new software capabilities rapidly to satisfy users and the desire to practice sound software engineering that reduces subsequent rework.

Increasingly, the software engineering community and those adopting agile techniques are interested in understanding how to quantify technical debt and manage debt pay-back strategies. Ozkaya observed that organizations are often driven to agile techniques after observing increasing technical debt in their software-reliant systems. Ironically, adopting agile practices at scale without considering their long-term implications can also easily lead to technical debt. Ozkaya's talk emphasized the need to explicitly acknowledge the tradeoffs between taking shortcuts in software development to accelerate product delivery versus applying slower--but less risky--software development methods.

Ozkaya questioned whether it is possible to avoid technical debt altogether, especially given the increasing scale and complexity of software-reliant systems, coupled with trends in the DoD and other government agencies to sustain systems that are expected to operate for decades. Another factor impacting technical debt is workforce diversity and turnover, which often yields distributed teams that must be managed remotely. Given these factors, Ozkaya said, it is inevitable that technical debt will accumulate since environments, systems, and technologies will change, so technical debt has become an ongoing software engineering practice that must be understood and managed effectively.

Recognizing the Financial Implications of Technical Debt

Technical debt has financial implications, just like monetary debt payments. Developers can choose to pay interest on their technical debt in the form of additional time and effort required to understand and modify poor structured code. Conversely, developers can pay down the debt by refactoring poorly designed code to reduce future effort. Ozkaya suggested that understanding the financial model implied by the "debt" metaphor can help establish the structural aspect of debt. These financial implications suggest the following questions that agile development teams must consider:

• What is the "interest rate" that organization signs up for when incurring technical debt?
• Can this interest rate be controlled?
• What is the period of the loan?
• What is it we're borrowing? Time? Or, other opportunities we need to bring to bear when managing timeline of loan?
• How do we create a realistic repayment strategy?

Identifying What Constitutes Technical Debt

Much of the existing literature on technical debt focuses on code-level issues, such as reducing the time needed to modify software functions, add new features, or fix bugs. Ozkaya said it's also important for organizations to consider how to best describe technical debt from architecture- and system-level perspectives.

The SEI focuses on managing debt as an agile software architecture strategy. Specifically, SEI researchers are focusing on identifying any implications to the cost of architectural changes. Often when a particular symptom in a system is described as technical debt, it's not just the code that is bad, but it's also accumulating problems that happen in terms of architectural changes that have occurred throughout the system's development.

To establish a common understanding of the term "technical debt," Ozkaya referenced the taxonomy of technical debt created by Steve McConnell. To date, much work has focused on McConnell's "Type 1" debt, which is unintentional and non-strategic. This type of technical debt often results from poor design decisions and poor coding.

Ozkaya specifically drew attention to the second type of debt described by McConnell: intentional and strategic, optimized for the present and the future. This "Type 2" debt can occur in an agile software development lifecycle when trying to accelerate development from a perspective that requires optimizing for short-term goals, such as shipping a product with known shortcomings to gain or protect market share. What is crucial when incurring Type 2 debt is to have a process for revisiting and reworking these short-term shortcuts to ensure system longevity.

Ozkaya also highlighted Jim Highsmith's prescription for managing technical debt. Highsmith focuses on understanding and monitoring the accumulating cost of change as a result of technical debt. As years or iterations go by and new functions are added or new technologies upgraded, the cost of change can start to increase dramatically.

Lastly, Ozkaya referenced Philippe Kruchten's perspective on technical debt, which focuses on emphasizing a value perspective on system development. Value could include features that have immediate benefit to stakeholders. Value can also be negative, such as defects that must be resolved. Most of the time, however, value that goes unrecognized are invisible aspects of the software, which are often architectural features that enhance the system when done well, but incur technical debt when done poorly.

Tracking and Analyzing Debt

Ozkaya presented three strategies for managing technical debt:

• Do nothing. When using this approach, it's important to understand the implications (both technical and economic) of "doing nothing."
• Replace the whole system. In some cases, this approach might have high cost and risk associated with it; in others, it might be precisely what is needed.
• Incremental refactoring (commitment to invest). An explicit focus on architectural agility becomes an instrument in this approach.

In large-scale software-reliant systems, the number of years spent before a system is launched is often detrimental to success since gaps in requirements and performance are not detected until very late in the lifecycle, when they are expensive to remedy. In such instances, using technical debt as a strategy and dividing the system delivery into chunks might be advantageous.

Ozkaya told the audience that eliciting and quantifying the impact of technical debt with pay-back strategies is not yet a repeatable engineering practice. Factors to consider in quantifying debt include tracking defects, changing velocity (what actually got done during an agile iteration versus what was planned), and the cost of rework. These indicators could be mapped into the cost of development, which yields a greater understanding of the value of paying back technical debt versus not paying it back.

Ozkaya's work focuses on quantifying technical debt, which can include code, though Ozkaya is most interested in quantifying debt early in the lifecyle, when code analysis alone may not provide enough direction. Specifically, Ozkaya's research focuses on understanding the right set of architectural models that can be used seamlessly within agile software development methods to provide feedback to development teams and help them understand the impact of rework. Ozkaya stressed that this rework might not be planned for, but could resurface as a change of requirements or technology.

Technical Debt Tools and Analysis

Among those organizations interested in managing technical debt, there is an increasing focus on tools for conducting structural analysis. Trends show increasing sophistication, support for structural analysis in addition to code analysis, and the first steps toward analyzing the financial impact of technical debt by relating structural analysis to cost and effort for rework. Several architecture-related capabilities also exist, including

• architecture visualization techniques, such as dependency structure matrix, conceptual architecture, architectural layers, and dependence growth
• architecture quality analysis metrics, such as component dependencies, cyclicity, architectural rules compliance, and architectural debt
• architecture compliance checking, such as defining design rules and ensuring that they are not broken, for example disallowing communication between certain components
• architecture sandboxing, such as providing features to enable easier discovery of the current architecture of the software, which may include navigating the file structure and moving components around easily

Deciding to Pay Down Debt

Ozkaya said the main motivation of structured technical debt analysis--and the emerging analysis tools--is to help organizations develop strategies for systematically paying down their debt. These strategies involve eliciting business indicators in a system that could be defined for a particular application domain and determining how those indicators are managed. Example indicators include

• increasing amount of defects. While this indicator may seem obvious, in some systems with many stakeholders, it involves an inability to deliver the system.
• slowing rate of velocity. At the first sign of slowing rate of velocity (the rate at which planned requirements for the iteration are being fulfilled) it could be easy to analyze implications (for example during an a sprint retrospect) and create an alternative strategy
• changing business and technology context. Often, organizations don't realize that a change in business and technology could result in technical debt in a system that has been perfectly fine heretofore
• a future business opportunity. The need to embrace new business opportunities could motivate the need to rework the system
• time to market. Time to market is another key indicator to consider when deciding to pay down technical debt or not

For large-scale software-reliant systems, adding technical debt to the backlog and continuously monitoring that debt should be common practice. Development teams can determine strategies for addressing and monitoring technical debt appropriate for the organization. For example, strategies could involve amortizing by 10 percent or conducting a dedicated iteration that focuses on paying back the debt.

Ozkaya also pointed to a recent Crosstalk article she co-authored that highlights architectural tactics involved in strategically managing technical debt. The principles of both agile software development and software architecture improve the visibility of project status and offer better tactics for risk management. These principles help software teams develop higher-quality features on time frames and on budget. The article described three tactics: aligning feature-based development and system decomposition, creating an architectural runway, and using matrix teams and architecture. Harmonious use of these tactics is critical, especially in large-scale DoD systems that must be in service for several decades, are created by multiple contractor teams, and have changing scope due to evolving technology and emerging needs.

Future Areas of Research

In describing future areas of SEI research on the strategic management of architectural technical debt, Ozkaya pointed out that this topic succinctly communicates key issues observed in large-scale, long-term projects, including

• solving optimization problems. In some cases focusing on optimizing for the short-term puts the long-term into economic and technical jeopardy when debt is unmanaged
• creating appropriate design shortcuts. Design shortcuts can give the perception of success, but cannot focus on the present alone, but need to consider future iterations and plan accordingly
• modeling software development decisions. Decisions concerning architecture should be continuously analyzed and actively managed since they incur cost, value, and debt. SEI research is focusing on opportunities for developing and quantifying effective payback strategies

In conclusion, Ozkaya recommended several immediate steps that organizations should take to managing technical debt:

1. Make technical debt visible, even if it's just acknowledging that there is a problem
2. Differentiate strategic, structural technical debt from unintended debt incurred as a result of factors like low code quality, bad engineering, or practices that have not been followed
3. Bridge the gap between the business and technical sides
4. Associate technical debt with risk and track it explicitly

What's Ahead

The first posting in this series on the SEI Agile Research Forum summarized discussions by Anita Carleton, director of the SEI's Software Engineering Process Management program, and Teri Takai, chief information officer for the DoD. Carleton provided an overview of the forum and discussed areas where SEI work is focused on applying agile methods at-scale. Takai then discussed how agile methods have been introduced into the DoD software acquisition and development environment. The second posting summarized discussions by Mary Ann Lapham, a senior researcher in the SEI's Acquisition Support Program, who highlighted the importance of collaboration with end users, as well as among cross-functional teams, to facilitate the adoption of agile approaches into DoD acquisition programs.

Our next posts in this series will summarize discussions of two SEI researchers, including myself, at the Agile Research Forum who examined the following aspects of applying agile methods at-scale in mission-critical development environments:

• James Over noted that lack of teamwork can critically impede agility. He advocated, among other principles, the building of self-managed teams, planning and measuring project process, designing before building, and making quality the top priority for achieving agility at-scale.

• Finally, I wrapped up the forum with a discussion on the importance of applying agile methods to crucial common operating platform environments (COPEs) at the DoD. I explained how agile methods can encourage more effective collaboration between users, developers, testers, and certifiers to help the DoD successfully build integrated, interoperable software systems.

We look forward to hearing your thoughts on applying agile at-scale in the comments section below.

Additional Resources

To view the Crosstalk article, Architectural Tactics to Support Rapid and Agile Stability, please visit
www.crosstalkonline.org/storage/issue-archives/2012/201205/201205-Bachmann.pdf.
To visit the International Workshop on Managing Technical Debt workshops website, please visit
www.sei.cmu.edu/community/td2012/.
To view the Hard Choices Board Games website, please visit
www.sei.cmu.edu/architecture/tools/hardchoices/.
To view blog posts about technical debt by Ozkaya and other SEI researchers, please visit
http://insights.sei.cmu.edu/archives.cfm/category/technical-debt.