How to Resolve Technical Debt: Pay-off and Prevention with Agility
Now that you have identified where your technical debt comes from, it's time to suit up and take control of paying it off.
Join the DZone community and get the full member experience.Join For Free
How to Resolve Technical Debt: Pay-off and Prevention with Agility
For decades, mainframe developers of various skill levels have updated and patched computer programs, introducing complex logic, performance inefficiencies, and dead code, creating for themselves piles of technical debt. Today, we're seeing this code become more difficult than ever for others, including many who are new to the mainframe, to change or work with, ultimately causing inefficiencies and/or resulting in rework that costs extra time.
These issues are becoming especially prevalent for mainframe teams moving from Waterfall to Agile. Two core objectives for Agile teams should be high quality and maximum throughput. Technical debt negatively impacts agility, speed, efficiency, effectiveness, productivity and performance.
In my previous post around the Agile root of technical debt, I talked about some of the specific areas from which it arises for mainframe teams that are moving faster in a digital world. The more of it you have, the greater the risk of software defects creating interruptions and unscheduled work. Poor quality negatively impacts the customer experience, and cleaning up technical debt takes time away from innovation and new development.
The obvious thing to do is strategize a way to pay off, manage and prevent technical debt. Here's how mainframe teams can do that from an Agile perspective.
Paying Off Technical Debt
Technical debt decreases velocity and impedes a team from getting its work done. Even so, many teams do not want to make addressing it a priority — product owners and stakeholders are often reluctant to give up their new development work to resolve technical debt, and most developers want to work on new code because it's more interesting and innovative work.
Customers and users don't request fixing technical debt because they don't directly see it, though they may see the results of it in poor performance, bugs and a clunky user experience, to name a few. The Agile team, which includes the product owner, the Scrum Master and every other individual team member, is responsible for making the identification and resolution of technical debt a high priority so it gets addressed and paid off as quickly as possible.
Based on my experience, there are three Agile approaches to paying off technical debt:
- Sprint-by-sprint: Reduce technical debt each sprint to still ensure the delivery of new features and to appease stakeholders.
- Dedicated sprint: Devote an entire sprint to addressing a large amount of technical debt.
- Outside normal sprint work: Pull capacity from normal sprint work to focus on technical debt work.
Which strategy or strategies you use will depend on your organization and its technical debt situation-the amount, criticality, work effort and impact of your technical debt. The point is to just start paying it off now — don't wait!
Managing Technical Debt
Even as you begin to pay off your existing technical debt, mainframe teams that are moving faster by utilizing Agile will still find it accruing. That's why it's important to immediately address current debt and figure out how you can manage it going forward so it doesn't get out of hand.
Enforce and Maintain a Strict Definition of Done
As discussed in my previous post, you should first determine why technical debt is accruing. A good place to start is to review your definition of done — if it's not completely adhered to, it's not done. No exceptions.
In Agile, at the end of each sprint, "done" means you have a workable deliverable that could be shipped to and used by a customer or business user. Your team shouldn't move on to a new story (task) until their current committed stories are in a deliverable state, meaning they satisfy the definition of done.
Determine How to Avoid Technical Debt
You should determine how technical debt can be avoided in the future, not with the goal of entirely avoiding it-it can't be-but with the goal of minimizing it. Teams will most likely become increasingly inefficient and unproductive if it is ignored.
One strategy for avoiding technical debt is to reduce velocity. Sometimes taking on less work results in getting more done in the long run. Reduce it while improving and not compromising quality by:
- Reducing scope instead of squeezing in extra features
- Not focusing on a schedule
- Focusing on high-quality, demonstrable deliverables
By reducing velocity, teams should not only address and reduce existing technical debt but also help prevent new debt. A team's velocity will increase as it is paid off.
Preventing Technical Debt
Addressing technical debt on a consistent basis will ensure it doesn't get out of hand and negatively impact throughput and quality. There are several steps teams can take to help prevent it as they become more agile.
By establishing and implementing DevOps best practices, teams will benefit from a consistent Agile development process to produce efficient and quality code and minimize technical debt. One of many examples includes requiring code reviews, where another developer reviews program changes to ensure they are readable, are understandable, and satisfy coding standards.
Technical debt is easier to handle when teams track and document it as a product backlog item as soon as it's identified so it isn't forgotten about and can be addressed. At Compuware, we use Atlassian JIRA Software to track all our work, including technical debt.
Self-documenting programs — the process of using descriptive variable names to make a system easy to use without prior knowledge — as well as implementing documentation standards and requiring peer reviews of documentation are other best practices that will help prevent technical debt.
Use Better Tools
It should go without saying, for mainframe teams to move faster and increase quality and throughput while keeping technical debt low, they will need modern alternatives to some of the antiquated, outdated tools they may currently use. For starters, you should be using:
- A source code management tool that enables developers to quickly and safely build, test and deploy code (Compuware ISPW).
- Debugging tools to accelerate application development and improve code quality (Compuware Xpediter and SonarSource products).
- Automated tools that enforce coding standards. (SonarSource products).
- Performance-enhancing tools to ensure your programs process as efficiently as possible. (Compuware Strobe and Compuware COPE for IMS).
- Automated testing (Jenkins, Compuware Topaz for Total Test and Compuware Hiperstation).
Obviously, you want to catch defects before your customers and users do. Manual testing makes this less likely because it slows a team down.
Major functionality should be automatically tested at the end of each sprint to ensure changed code does not inadvertently break existing functionality. New automated tests should also be written as part of the definition of done to ensure new functionality behaves as intended.
The same can be stated whenever a bug is discovered. You can build an automated test to execute and ensure the bug fix resolves the defect and future code changes won't reintroduce the defect.
Code protected by tests provides developers additional confidence that their code changes work and don't cause new bugs, which, if undetected and not fixed, result in new technical debt. This is especially important in older applications where developers are not familiar with complex code or the reasons why existing functionality was coded in a particular manner.
Make Technical Debt a High Priority
Ignored, technical debt will increasingly decrease a team's productivity and quality. Developing a plan to pay off, manage and prevent it is critical to helping your team achieve and maintain a high, stable velocity with optimal quality. Make technical debt a high priority for your teams and start addressing it now — don't delay.
Compuware is ready to help.
The following two tabs change content below.
Published at DZone with permission of Don Clos, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.