Software Debt Concepts

A Brown Bag Debt Discussion

Disclaimer: This document was created to get a
conversation started, simply to get everyone thinking,
and is subjective in nature. I’m interested to see what
your thoughts on these topics and how we can
leverage understanding the challenges that affect us
to improve our delivery, velocity, quality, and
cadence. I have included reference material at the
bottom if you would like to know the sources of some
of the information.

There are several types of debt that can cause delays, impediments, and future work efforts for a team
so by understanding the different types we can improve our delivery cadence by being able to identify,
manage, and escalate issues sooner. These are realized in the following types of Debt: Technical,
Feature, Quality, User Experience, Process, Change Management, and Skills. Feel free to offer your
thoughts and opinions too.

The Concept of Software Debt

The Concept of Software Debt can be an effective way to communicate a program’s need for
refactoring, improvement tasks, complete criteria, better quality, skill needs, impediment identification,
etc. Due to timing, skills/capabilites, dependencies, complexities, and negotiations, we may need to
deliver features that are not optimal or fully realized so we accept the risk and defer that effort to the
future; this is debt. As a program, we are constantly incurring debt on our features which is affecting
the delivery of our goals. Don’t worry, this is normal, but we should take a hard look at the types of
debt we are incurring so we can know how to manage it and get better at addressing it in the future.

As we identify a type of debt for a feature, we should understand if it is an impediment, additional work
effort, or opportunity for improvement. If that work effort/debt is critical for feature acceptance and
may impact our delivery schedule, we should determine a plan of action to pay off that debt in the
current sprint, future sprint, or a future PI. If we realize the debt is causing impediments, we should
raise the issue to our SM, RTE, or PM’s. Improvement stories can be discussed during retrospectives and
taken on by the team.

What are the types of debt?

Today I brought up the concept of Technical Debt on our call and I wanted to be clear, not all software
projects issues are Technical Debt. For the group on this email, one of our biggest challenges is Feature
Debt. Let’s look at some of the common cases we are running into…

“While developing a story, it was more complex than we thought and an additional object structure will
have to be explored and redesigned to accommodate the feature fully. We have a workaround that
covers most cases for now, so accepting this ‘as is’ allows us to meet our delivery date.”
“Due to the varying delivery dates with a dependency, we had to develop our feature with information at
hand for a dependent system and feature that had not been fully realized yet, so we are likely expecting
some integration changes to be realized soon.”
“Due to the complexity of the feature, we soon realized that the path we had chosen to develop may not
have been the most ideal for future feature additions. It works for now, but we will need to refactor it if
we make further changes.”
“Since several developers worked on this feature, when we merged the code branches, there is lack of
consistency and notation in the code. We will need to refactor and clean it up.”
Stories that are delivered ‘not quite right’ or include ‘throw-away/band-aid’ code that will not support
the optimal solution are examples of Technical Debt.

“Due to the compressed timeframe of our deliverable date, we were unable to implement the dynamic
field function so it is static now. We need this in the future, but it is a lower value, and accepting this ‘as
is’ allows us to meet our delivery date.”
“For a story in our current sprint, we were almost ready to deliver but we realized we missed a scenario
that needed additional functionality added to achieve the desired function. Unfortunately, it was a “must
have” so we have to slip our story to the next sprint which will impact our Velocity.”
“We are almost done developing a current sprint item, but the BO came back with a delayed answer that
will require us to add an additional rule to our feature. The addition rule was a lower priority, so
accepting this ‘as is’ allows us to meet our delivery date. We need a future effort for this though.”
Wrong, missed, or delayed feature criteria are not Technical Debt. They are Feature Debt.

“During testing, the business noticed the UX is sluggish when selecting multiple products at the same
time.”
“During testing, we noticed several small bugs where the feature would work intermittently but we could
not recreate them.”
Identified defects are not Technical Debt. They are Quality Debt.

“It’s not intuitive to see the error message in its current location at the bottom of the page, a popup
would be more ideal so users can easily realize the error.”
“As I browse through the pages, the “back” buttons are not in the same location which is confusing”
“I’m noticing that the branding and layout does not match between pages”
Inconsistent or poor user experience is not Technical Debt. It is User Experience Debt.

“Our team completed the development on a service for another teams feature that is currently WIP, but
we’re not sure who owns the E2E testing and integration efforts; as they may incur additional work and
delivery delays to utilize the service.”
“Our lead developer has left the organization and he did create any support artifacts for the features he
created, we need to recreate them to develop the next feature.”
“The last developer did not update the support documents and we are unsure which code branch is the
correct one”
“We are having to spend a lot of time manual validating our data quality with dependent systems, can
we automate this? Let’s set up an improvement story for this.”
Lack of process or poor process is not Technical Debt. It is Process Debt.
An example is Configuration Management Debt.

“I am assigned a deliverable that is for a new tool we will be using, but I need to learn how to do this tool
before I can complete the deliverable.”
“We have 2 new team members who are getting up to speed on our systems and processes, so we may
experience some delays.”
“Our team is not fully eliciting all the feature rules and workflow scenarios prior to features starting
development and stories are regularly needing re-work and additional effort, we are looking for ways to
improve that.”
Lack of skills is not Technical Debt. It is Skill Debt.

What kind of debt is your team incurring and how do you plan to manage and track it in Jira and
AgileCraft?
What types of debt will you review in your retrospective and create improvement stories for?

As we move more CI/CD, we want to understand Technical Debt more clearly.

So, what is Technical Debt?

When delivery dates are aggressive or team capacity/skills are limited and short cuts are taken, or when
code is delivered that is not quite right for the programming task of the moment, a development team
incurs Technical Debt. This debt decreases productivity and incurs a future effort cost. This loss of
productivity is the interest of the Technical Debt.

What incurs Technical Debt?

Code that is not quite right may include many types of issues. These issues may be related to
architecture, structure, duplication, test coverage, comments and documentation, potential bugs,
complexity, code smells, coding practices and style. All these types of issues incur technical debt
because they have a negative impact on productivity.

Why do we use the “Debt” metaphor?

The Technical Debt concept is a way to describe the need for refactoring and improvement tasks related
to the source code and its architecture. Technical Debt may emerge during the life of a project and
sometimes isn’t realized until you begin the technical work or when architecture changes happen in the
future. When we apply this concept of debt to other issues we face, we can identify impediments and
dependencies more transparently.

What is Refactoring?
Code Refactoring is the process of clarifying and simplifying the design of existing code, without
changing its behavior. Agile teams are maintaining and extending their code a lot from iteration to
iteration, and without continuous refactoring, this is hard to do. This is because un-refactored code
tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad
allocation of class responsibilities, way too many responsibilities per method or class, duplicate code,
and many other varieties of confusion and clutter. Every time we change code without refactoring it, rot
worsens and spreads. Code rot frustrates us, costs us time, and unduly shortens the lifespan of useful
systems. In an agile context, it can mean the difference between meeting or not meeting an iteration
deadline.

Technical Debt Quadrant

Sometimes debt is deliberate based on delivery needs and sometimes it’s inadvertent from an
unrealized complexity. This applies to several types of debt.

If you would like further information on these topics, I summarized several topics from these sites:
https://www.agilealliance.org/introduction-to-the-technical-debt-concept/
https://www.agilealliance.org/project-management-and-technical-debt/
https://www.versionone.com/agile-101/agile-software-programming-best-practices/refactoring/
http://www.managingsoftwaredebt.com/category/configuration-management-debt/
https://www.scaledagileframework.com/develop-on-cadence/
https://www.benlinders.com/2015/process-debt-agile-step/