Crushed By Technical Debt?

 

On Wednesday October 21, 2015 we hosted a webcast entitled “Crushed by Technical Debt?” A PDF of the slides can be found on Slideshare.  The webcast addressed the following issues:

• What is technical debt?
• How can we avoid technical debt?
• How do we identify technical debt?
• How do we fix technical debt?
• When should we accept technical debt?
• How can we fund technical debt?

As you can imagine we ran out of time to answer all of the questions that we received during the presentation. Below are answers to all of the questions we received, even the ones that were answered during the Q&A portion of the webcast. The questions, and their answers:

• Stories for technical debt?
• How to convince product owners about technical debt?
• Too many warnings from your code analysis tools?
• Too much technical debt?
• Measuring technical debt?
• Fix or start from scratch?
• A negative awareness score for senior business management?
• Forecasting technical debt?
• Can architecture owners work on multiple teams?
• Where are the goal diagrams?

Additional topics:

• A special thank you
• Related reading

Question: What’s your opinion regarding separating tech debt into separate stories?

This is one way of doing it. At one point during the presentation we discussed three strategies for how to fund paying down technical debt.  These three strategies are:

1. Technical debt removal as regular investment. The idea is that developers automatically pay down technical debt, just like you would automatically clean up spilled juice in the middle of your kitchen floor, whenever you run into it.  In effect paying down technical debt becomes part of your culture.
2. Stories to address technical debt. The idea is that you have requirement artifacts, such as technical stories, to remove a small amount of technical debt within your environment.
3. Projects to address technical debt. With this approach you have specific projects to rewrite portions of an IT solution, or perhaps even to remove that solution completely.

Question: How to convince Product Owners to address Technical Debt?

Product Owners (POs) are responsible for prioritizing the work. When technical debt is addressed via stories then the PO can easily deprioritize such stories.  The implication is that the team members, and in particular the Architecture Owner, must work closely with the PO to help them to understand the implications of technical debt and why it’s important to pay it down.

When technical debt is addressed automatically via regular investment, it is a built in overhead that affects your team’s overall velocity (negatively in the short term, but positively in the long term.

Question: What do you do when there are to many warnings thrown by your code analysis tools?

Regarding using code-analysis output as a metric: do you have any specific advice for dealing with the scenario with legacy code where it will initially overwhelm you with thousands of issues, from the trivial (i.e. spelling mistakes) to major : i.e. should one start by switching off the trivial warnings and deal with the major, or start fixing the big-numeric-count issues no matter how trivial just to get the numbers down?

It’s harsh to say, but the reason why you’re getting a lot of warnings is because the code sucks. When this is the case, it’s important to recognize the situation for what it is and get going on fixing the problems.

Initially I would turn off a lot of the lower priority checks so that the team could focus on the critical issues with their code. Once they refactor those away then I would turn on the next group of high-priority checks and so on until the problems are dealt with.  This could take a long time, so you’ll need the discipline to stay at it.  Perhaps start each retrospective with the question “How many code checks can we turn on this coming iteration?”

Question: Lack of (enough) clean code from the first time?

This is always a major frustration for people.   It is incredibly rare to be in a situation where clean code was written from the very beginning and then kept clean via techniques such as refactoring.   Instead most people find themselves swimming in legacy code, data sources, user interfaces, and so on that contain lots of technical debt.  Our advice is to accept:

• The situation that you find yourself in
• That the technical debt isn’t going to fix itself
• It’s only going to get worse
• You need to start paying down your technical debt now

If it makes you feel any better, and it likely won’t, the 2014 Software Development at Scale survey found that 92% of agile teams were facing some form of technical complexity.

Question: How we should measure technical debt?

There are many different ways to measure technical debt, all focused around solution quality. You may choose to measure code quality, perhaps in an automated fashion via code analysis tools, for example.  You may also choose to track defect trends over time, although that can easily become a measure of how good you are at testing instead of the quality of what you’re producing.

Question: How do I know if it’s better to fix technical debt or start all over from scratch?

This typically comes down to a gut feel based on your experience doing such work in the past.

Question: What does a negative score for technical debt awareness means? How should that be read & interpreted?

This is a reference to one of the charts from the 2015 Agile Cadences and Technical Debt Survey, see below , where senior business management had a negative score.  The range is from -10 (very unaware) to +10 (very aware).  So on average business management leaned towards being unaware of the implications of technical debt.  This is a problem seeing as the business needs to fund the removal of technical debt.

Question: Is there any best practice/method to forecast Technical Debt?

Unless you really have your act together, the forecast is that technical debt is going to get worse over time.  Seriously though, that’s why you need to have a technical debt metrics program in place. In this case you want to track the trends over time, and simply extrapolate those trends to forecast the implications to your organization of technical debt.

Question: Can one architect span multiple teams? That is, is it a good idea to have the same person as the architect across multiple teams?

In Disciplined Agile we explicitly include the role of Architecture Owner (AO), which was adopted from the Agile Modeling methodology. This is effectively an agile solution/application architect who works in a collaborative, evolutionary, and facilitative manner.  Every delivery team should have someone in the AO role to help guide them through architectural issues.  Ideally each team has one person in this role and they are dedicated to the team full time, just like other team members.

Having said that, as we like to say “you go to war with the army that you’ve got.” For example, you may have ten agile teams but currently only four people with the skills to be an AO.  In this situation each AO is going to be a member of two or three teams.  As a result they will suffer a personal productivity loss from task switching and their teams will suffer a productivity loss from having to sometimes wait for them to be available.  This isn’t ideal but it’s the reality that many organizations face.  The solution is for the AOs to work collaboratively with other team members so as to start passing on their skills and knowledge to them, to help grow their fellow team members.

Question: Are the goal diagrams available in a single document?

Great question. Sadly the quick answer is that there isn’t a print-based one at the current time.  Our focus has been on publishing to the web, ignoring the fact that we recently published the 104-page book Introduction to Disciplined Agile Delivery. We have published a landing page for the Process Goal Diagrams for Disciplined Agile Delivery. We are also actively publishing the goal diagrams for the process blades, such as Enterprise Architecture and Portfolio Management, as well.  The easiest way to access them is from the diagram on the Disciplined Agile Home Page (just click on the corresponding bubbles). This is a work in progress and we hope to have the process blades descriptions in place by December.

Having said that, we have been thinking about publishing some sort of “Disciplined Agile for Coaches” book that would include all of the goal diagrams.

A Special Thank You

We’d like to give a shout out to Valentin Tudor Mocanu for answering several of the questions in the chat window while Scott was speaking.  

Related Resources

• Article: 11 Strategies for Dealing with Technical Debt
• Slides (PDF): Crushed by Technical Debt?