Development Debt

Development Debt

In Technical Debt, we noted that technical debt is a metaphor coined by Ward Cunningham to represent the work not done or the shortcuts taken when delivering a product. Cunningham uses the term to describe issues in software code. As with any good metaphor, it can be used to stand in for short cuts in other deliverables that effect the delivery of customer value.  In fact, a quick Google search shows that there have been numerous other uses. These “extensions” of technical debt include:

  • Quality Debt,
  • Design Debt,
  • Configuration Management Debt,
  • User Experience Debt, and
  • Architectural Debt.

Before I suggest that this extension of the technical debt metaphor represents a jumped the shark moment,  I’d like to propose one more extension: process debt.  Process debt reflects the shortcuts taken the process of doing work that doesn’t end up in the code.  Short cuts in the process can affect the outcome of sprint, release, whole project or an organization’s ability to deliver value. For example, teams that abandon retrospectives are incurring process debt that could have long-term impact.

Short-term process debt can be incurred when a process is abridged due to a specific one-time incident. For example, failing to update an application’s support documentation while implementing an emergency change. In the long run, support personnel might deliver poor advice based on outdated documentation, thereby reducing customer satisfaction.  The one-time nature of the scenario suggests that the team would not continually incur debt purposefully. However if process debt becomes chronic, an anti-process bubble could form around the team.  Consider how a leader with a poor attitude can infect a team.  High quantities of process debt can reflect a type of bad lead syndrome that will be very difficult to remediate.

An example of process debt I recently discussed with a fellow coach occurred when a team that was supposed to do a code check-in every evening for their nightly build called a week hiatus.  The overall process was that code was to be checked in, followed by a consolidated build of the software, and then it was to be subjected to a set of automated smoke and regression tests. A significant amount of effort had been put into making sure the process was executed, however the person that oversaw the process got the flu and no one else had been trained. The lack of executing a nightly build process allowed the code to drift enough so that it could not be integrated. It took twelve days and a significant amount of rework to get to a point where a nightly build could be done again.  The process debt was incurred when a backup was not trained and the process stopped being used.

Peer pressure, coaching and process and product quality assurance (PPQA) audits are tools for finding, avoiding and, when needed, remediating process debt.  In all three cases someone, whether a fellow team member or an outsider, will need to look at how the work has been done in order to understand how the process was followed.

Process debt equates to shortcuts in the use of the process that can impact a team, a project, project deliverables or the long-term ability of the organization to deliver value to their customers.  What process debt is not is experimentation done by teams consciously in order to improve. Process debt is not change made to a standard process that does not fit their context adopted during retrospectives. Process debt is incurred when teams abandon a process without a better process. Process debt stands as a worthy extension of the technical metaphor that can help us understand that shortcuts in how we do our work can have ramifications, even if the code is not affected.