Terminology: Technical Debt

Photo by Anton Bielousovt

Photo by Anton Bielousovt

I realize that the idea of technical debt is already a metaphor, but I’ve found that it often comes with a stigma that bad decisions were made in the past, which is not always the case. And people sometimes don’t understand the severity of the technical debt that is accumulating in their systems. It's not just developers who should care about technical debt.

As another way of explaining technical debt, I’ve been thinking about the game Twister. In each turn of the game, the player has to make a decision about how to place his hands or feet on the colored dot that the spinner has indicated. Similarly, developers decide the architecture/design to use as they implement features. Early on in the game and in a new software project, these decisions are relatively simple. You tell the player to put his right-hand on red, and he can do this fairly easily.

But as the game continues, the decisions become more difficult. The player is contorted on the board, making his position more difficult to move from. His previous decisions were not necessarily bad, but it is challenging to make the next move.  Similarly in software, the architecture and designs used were not necessarily wrong, but they do not enable delivery of future features. For that reason, the player/developers must “refactor” the state they are in. 

And if the position that the player finds himself in does not get refactored to a more stable state, then he eventually falls down and loses. Game over. We do not want this for our software systems either—it is the point where we declare technical bankruptcy. Pay off technical debt early.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

The High Cost of Delaying Maintenance and Knowing Better

Photo by Doug Waldron

Photo by Doug Waldron

My car had been making noise for a few weeks, but I kept making excuses rather than take the car to the mechanic--I was just there for an oil change and don't want to go back so soon.  I don't have time to take my car to the shop during the week because of work.  I don't know what to tell them is wrong.  

I ended up taking my car to the shop right before I went on vacation, but it was to a collision centerbecause someone hit my car in a parking lot two days before I left.  One of the employees told me my car was rather scary to drive, reinforcing what I already knew.  My car ended up making the decision for me when a brake pad fell out at the collision center--my car needed to go to the mechanic ASAP.  It cost me over a thousand dollars and caused me to be without my car for a couple of days, but my car finally got the attention that I knew it had needed for quite a while.

Similarly, individuals, teams, and organizations are regularly delaying "maintenance" that is needed to keep things running smoothly--taking training classes, giving performance reviews, reducing technical debt, notifying stakeholders of changes, cancelling projects, revising policies... the list goes on and on.  The cost of delay is significant.

You already know what you're putting off, so what are you going to do about it?

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Code Quality, Technical Debt, and Scrum Masters

Photo by Images Money

Photo by Images Money

According to the Scrum Guide, a Scrum Master's responsibilities include s "Teaching and leading the Development Team to create high-value products."

For software projects, does this mean that a Scrum Master needs to know how to write high-quality code and automated tests plus any necessary documentation and training materials?  No.  But to balance the Product Owner's focus on delivery of features and ROI, the Scrum Master should be concerned with quality (and not delivery) and therefore facilitate a team quality mentality and remind the team of its Definition of Done.

And given the number of projects I've seen that deal with legacy code, Scrum Masters also need to be aware of technical debt.  The best attitude to take towards technical debt is this:

...when it comes to creating technical debt, the one thing you must do is, stop. No matter what, you must not create more. And, if you wander into some code or tests that have technical debt, I do not see how you can be a professional and leave it there.

It might not be the most popular attitude with the development team initially, but it's the one that can do the most good in the long-term.  Johanna Rothman has some great actionable steps a team can take to manage technical debt.  A Scrum Master also needs to be able to pick up on the signs of technical debt when talking with team members, perhaps even asking them questions to understand how much debt there is.

A Scrum Master doesn't need to know how to develop the product himself, but he should be able to guide the team to develop a high-quality product.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.