In a previous blog I classified technical debt as naive, unavoidable, and strategic. In this blog I focus on three approaches to managing the accrual of technical debt:

• Use good technical practices
• Use a strong definition of done
• Properly understand technical debt economics

Let’s examine each.

Use Good Technical Practices

The first approach for managing the accrual of technical debt is to stop adding naive technical debt to products. Naive technical debt is a form of technical debt that accrues due to irresponsible behavior or immature practices on the part of the people involved. Using good technical practices is an excellent starting point for avoiding naive technical debt. Example good technical practices include:

• Test-driven development (TDD)
• Test automation
• Continuous integration
• Refactoring
• Pair programming
• And so...

Failing to understand or use these technical practices will likely result in poorly constructed solutions that are defect-ridden, prone to failure, and hard to maintain and extend.

Use a Strong Definition of Done

Another important approach to managing the accrual of technical debt is to have a strong definition of done. Conceptually the definition of done is a checklist of the types of work that the team is expected to successfully complete before it can declare its work to be completed (potentially shippable in Scrum). Work that we should have performed when a feature was built, but ended up deferring until a later time, is an important cause of technical debt.

The more technically encompassing we make our definition-of-done checklist, the less likely we are to accrue technical debt. The cost of paying back technical debt that slips past a weak definition of done is substantially greater than addressing it during the sprint (since early debt compounds). Operating without a strong definition of done is like granting a license to accrue technical debt.

Properly Understand Debt Economics

To use technical debt strategically and advantageously, we must properly understand how it affects the economics of our decisions. Sadly, most organizations don’t understand the implications of technical debt well enough to correctly quantify the economics of taking it on. As a result they wrongly conclude that accruing technical debt is the proper thing to do.

An argument for accruing technical debt might be: “If we take on the debt and accelerate the product into the marketplace we will increase lifecycle profits by $500k; the cost of paying back the debt would only be an incremental $100k.” If these numbers were accurate, then it would appear sensible to take on $100k of debt to generate $500k of revenue. However, my experience is that most organizations don’t consider all of the relevant variables to properly quantify the economics when they intentionally take on technical debt.

Here is a sample of what would be involved in quantifying the economics. First we would need to determine what the benefit is of taking on the technical debt. Most organizations that take on technical debt do so to accelerate a product into the marketplace. So the benefit of the accelerated delivery could be quantified by calculating the cost of delay of not accelerating the product into the marketplace. Meaning, what would be the impact on lifecycle profits if we did not take on the debt and accelerate the product into the marketplace? There are many variables that factor into a proper cost-of-delay calculation (a topic for a future blog posting).

We would then need to consider the cost of taking on the debt. When calculating the cost it is very easy to miss important variables. Obvious things to consider are:

• Additional work we will have to do in the future to payback the debt
• Interest payments we will make on the debt until it is repaid
• The cost of delaying the development of future products or the next release of the current product. Think of it this way, the time required to perform the extra work in the future to repay the accrued debt delays us from working on these other products and they each therefore suffer a cost of delay.

As you can imagine, there may be many other not-so-obvious costs associated with accruing technical debt.

Of course, if the economics in favor of taking on the debt are overwhelming and compelling—for example, we will go out of business if we don’t take on that debt and get the product into the marketplace with all of the must-have features, or we will miss being first to market and lose the lion’s share of the marketplace revenue—we don’t need to spend time considering less important cost factors because we already know it’s economically sensible to take on the debt.

More often, however, the decision isn’t so clear-cut. The choice of whether or not to assume the debt usually requires detailed analysis to discern which is the better option. When deciding, err on the side of not taking on the debt. In my experience, most organizations substantially underestimate the true cost of assuming technical debt and aren’t nearly as diligent as they think they will be at repaying it.

Closing

The purpose of this blog posting is to discuss managing the accrual of technical debt—one of three activities for managing technical debt. In the next two blog postings in this series I will discuss the other two activities: making technical debt visible and servicing (repaying) technical debt.

I agree there are times that I want to know how the development team is performing, so I will address that question in this blog. However, that question is of much less relevance to me than questions like: “How are we performing as an agile organization?” or “How is a Scrum team performing?” Answers to these questions provide insight at a more economically relevant and actionable level.

At the organizational level I want to know if are we delivering desirable customer value in an efficient manner. To understand if we are, I would measure things like:

• Idle work versus idle workers — measure when and how often the flow of work is being impeded (rather than how busy we keep people).
• Delivery of working and validated assets — delivering on time and on budget doesn’t really matter if we don’t deliver a product people want to use.
• How quickly we as an organization are learning — using things like innovation accounting (a Lean Startup concept) that evaluates how fast we are learning as a measure of our progress towards converging on a business-valuable result.

Below the organizational level I want to focus on the full Scrum team. It takes all three roles to deliver the right customer value and to deliver it well. So I am interested in measuring things like "Is the Scrum team delivering good value every sprint?" (more on this shortly).

But what if we want to measure just the development team (hereinafter just “team”)? Perhaps we want to know whether we made good choices when assigning people to teams. If development teams are going to be long-lived assets, then we will want to know how well these teams are performing.

I begin the discussion of measuring development teams by ruling out the use of velocity and instead suggest other measures including:

• Team meets its sprint goal most every time
• Product owner believes that the team is delivering good economic value
• Team is working at a sustainable pace
• Team has or is acquiring relevant T-shaped skills
• Rate at which the team is learning

Velocity (Do Not Use This)

For many people, velocity is an obvious way to measure team performance. Unfortunately, velocity should only be used as a planning tool (e.g., release planning) and as a team diagnostic measure (e.g., are process improvements working). It should not be used as a performance metric in an attempt to judge productivity. Velocity is simply too easily gamed to use it for productivity measurement purposes. If team members know that velocity is the measure that people will use to judge the performance of their team, they can arbitrarily increase the size of the product backlog items (point inflation) or cut corners to get more things done each sprint. In my Essential Scrum book, I provide a detailed description of what velocity is, how it should be used, and how it can be misused. For our purposes here, I will not include velocity in a multidimensional measure of team performance.

Achieving Sprint Goals

Okay velocity is out, so what should we use to measure team performance? One indicator of how a team is doing is the frequency at which the team meets its sprint goal. As a rule, every sprint should have a goal (like an executive summary statement) that the team commits to achieving. I want a team to achieve its goal most every sprint. I’d prefer that a team not achieve its goal every single sprint since that might be an indicator that the team is habitually under-committing. Occasionally, I want a team to have made a solid attempt to achieve the goal but to miss it, for the right reasons (e.g., the goal was bit of a stretch). That better indicates to me that the team is likely performing at its reasonable limit.

Delivering Value

An easy and appropriate check and balance on “low-ball” team commitments is to ask the product owner whether or not she is getting good value each sprint. Most sprints are performed at a fixed cost—we know who is on the team and we know the duration of the sprint, therefore we know how much it costs to run the sprint. Let’s say it costs $20k to run each sprint. An important question to ask the product owner is “Do you feel like you are getting at least $20k of value each sprint?” A good product owner will know the answer to this question. If the product owner says, “Yeah, I am happy with the value that team is delivering,” then that is an indication of good team performance.

As a note, the product owner has overall responsibility for the economic outcome at both the sprint and the release level. So, if the product owner naively spends $20k and asks the team to work on product backlog items that deliver $10k value, then the product owner is not performing well. Overall, delivering good value is a responsibility owned by the entire Scrum team (product owner, ScrumMaster, and development team), but it is factor to consider when evaluating the development team.

Working at a Sustainable Pace

I also want to know if the team is delivering good value nearly every sprint at a sustainable pace. We have all seen team members work 80 hours a week to deliver on their sprint goal. The first reaction might be, “See, I have a great performing team because they are willing to work so hard to get the job done!” Every now and then it might be necessary to work longer and harder during a sprint to get the job done. There can always be the unpredictable event that causes a bit of a crunch. However, people can’t work at an unsustainable pace for an extended period of time, so team members that work 80 hours a week won’t be a “great” team for long, they will soon be a "burnt-out" team. So, my third indicator of a good performing team is does it delivery good value most every sprint while working at a sustainable pace.

Increasing T-shaped Skills

Another measure of good team performance is: "Do team members have and are they working to further develop their T-shaped skills?" T-shaped skills is a metaphor I use to describe a person with deep vertical skills in a specialized area as well as broad but not necessarily very deep skills in other relevant areas. Teams composed of members with T-shaped skills are more resilient to fluctuations in the work, since it is likely that more than one team member can work in a given area, and therefore teams can swarm people to areas where there is an abundance of work to perform. I believe that the degree to which team members have and are acquiring T-shaped skills is an important indicator of team health and performance.

Learning Fast and Frequently

Finally, there is the rate at which the team is learning. In particular, I am interested in the rate at which the team is completing its learning loop of: assume, build, feedback, inspect, and adapt. High-performing teams never let important assumptions live long before validating them and acting on what they learned. High-performing teams organize the work in a way that maximizes their ability to learn important details fast, so they can adapt to what they are learning.

Given the importance of learning fast and frequently, I would apply this measure at the organization and Scrum team levels as well. Just like teams that are quickly learning important information tend to do the best work and outperform slow-learning teams, organizations that learn the quickest tend to trounce their competition.

Summary

To summarize, when measuring performance, first consider higher levels like organizational and Scrum team levels. And, when evaluating the development team, don’t use velocity. Instead consider a multidimensional set of measures like the ones I discussed in this blog to get a more encompassing picture of team performance.

One final observation. In my experience good managers within an organization don’t really need any formal metrics to determine how well their teams are performing. Such managers stay in close contact with the people doing the work and they are keen observers of what is actually taking place. Ask a good manager about the performance of any team she is associated with, including its strengths and weaknesses, and she will be able to give you an immediate, informed answer to that question.

Technical debt is a term used to describe the obligation that a software organization incurs when it chooses a design or construction approach that is expedient in the short term but that increases complexity and is more costly in the long term. To facilitate a discussion on technical debt I use the following taxonomy to describe how technical debt might be accrued:

• Naive technical debt
• Unavoidable technical debt
• Strategic technical debt

Let me describe each of these.

Naive technical debt

Naive technical debt is a form of technical debt that accrues due to the irresponsible behavior or immature practices on the part of the people involved. For example, team member naiveté that leads to sloppy design, poor engineering practices, and a lack of testing are frequent causes of naive technical debt. Business people immaturity can also lead to this form of debt. For example, by over-constraining the variables of date, scope, and budget, business people frequently force technical people to take shortcuts to deliver an unreasonably large set of features in the face of insufficient time or resources. It is naive for business people to believe that just because they want (or must have) all the features by a given date at a certain price that they can get it at a reasonable quality level!

Unavoidable Technical Debt

Unavoidable technical debt is a form of technical debt that is usually unpredictable and unpreventable and accrues through no fault of the team building the product. A common example is the need to evolve a design over time as we learn more and more about the problem we are solving and how best to solve it. It is unrealistic to assume that early on during the development of a product, when we have rather poor information about what to build and how to build it, that we can come up with a design that will work well both now and in the future. As we gain better and better information about what we are building and how to build it, an early design that seemed quite satisfactory or even brilliant when created can become far from adequate in ways that we could have never predicted when the original design was created. In this sense we have accrued unavoidable technical debt. We will want to refactor the design to make it better suited to our new current reality.

Another example of unavoidable technical debt would occur if we licensed a third-party component for use in our product and the interfaces to that component evolve over time. Our product that once functioned well with the third-party component accrues technical debt through no fault of our own. Although this debt might be predictable (it’s not unreasonable to assume that the vendor will change its component interfaces over time), it’s not preventable because we can’t foresee how the component developers might evolve the component in the future.

Strategic Technical Debt

Strategic technical debt is a form of technical debt that is used as a tool to help organizations better quantify and leverage the economics of important, often time-sensitive, decisions. For example, an organization might deliberately make a strategic decision to take shortcuts during product development to achieve an important short-term goal, such as getting a time-sensitive product into the marketplace. Also, for a capital-strapped organization that is at risk of running out of money before it can complete its product, getting a product with technical debt to market at a reduced initial development cost and then generating revenue to self-fund ongoing development may be the only way for the organization to avoid death before deployment.

To use technical debt strategically, we must properly understand how it affects the economics of our decisions. First we must reasonably quantify what is the benefit of accelerating a product into the marketplace. Then, we must compare that benefit against the incremental cost of having to repay the technical debt with interest in the future. We also have to factor in the time it will take to repay the debt, and then determine what the cost of that time is in terms of delaying other products or the next release of the current product.

Closing

The purpose of this blog was to introduce a taxonomy for discussing how technical debt is accrued. In the next blog posting on this topic, I will begin to address how to manage technical debt when performing agile development.