Mounting technical debt is similar to damage caused by termites–left unchecked, both can cause major problems. When technical debt creeps in, development becomes harder, the codebase becomes brittle, and tribal knowledge is required to understand hacks and known workarounds. Technical debt needs to be addressed and avoided in the future, but this is a difficult goal to strive for.
Here at Atlassian, teams reduce technical debt by first identifying what it is, developing a plan to iteratively reduce it, and finding creative ways to enable developers to organically make the codebase better. Keep reading to learn more!
Step 1: Identify technical debt
At first glance, many people assume technical debt = bugs. Sure, bugs are a certain kind of technical debt, but technical debt is more than just bugs. Technical debt is outstanding work promised but not delivered to the customer, defects in the code, or work items that hurt agility. Because technical debt can manifest itself in so many ways, there’s often a point of contention between development teams and product owners. Where do you draw the line between technical debt and new feature work?
At Atlassian, teams create a page in Confluence that outlines the team’s definition of technical debt. These best practices can be used as a guide for future conversations around managing a team’s technical debt in both planning and delivery.
Realize, though, that not all technical debt is the same and will have different priorities and paths to resolution.
- Bugs: tend to be small in scope and have a more urgent nature about them
- Incomplete feature work: features that weren’t developed to the team’s implementation standards. Note that new feature work not delivered may not be technical debt. This is up to the discretion of the team and how they define technical debt.
- Out-of-date code libraries: stale code and old versions of code
- Build and deployment tooling: build and deployment issues can be categorized as technical debt. Ensure the team has a process to develop and release quickly.
Jira has many features to help teams define and tame technical debt. Using Jira’s issue types, it’s easy to classify different kinds of technical debt in each issue. Discussions between product management and engineers are more grounded when clear definitions of technical debt exist in the different issue types.
Jira’s dashboards also help manage technical debt, because they can visualize and keep track of technical debt. The two-dimensional filter statistics gadget outlines when technical debt was introduced and when the team expects to resolve those issues.
The created versus resolved gadget highlights the flow of technical debt across the team. In an ideal world, this chart would show more green than red, and it’s perfect for a wallboard because it’s so visual.
These best practices and gadgets bring transparency to technical debt and can easily help a team prevent potential major problems in the future.
Step 2: Manage one backlog
Teams lose the strategic advantage of making priorities global across the product when technical debt is not in the same backlog as new features. Having all work items in one place makes everyone’s job easier, because priorities are clear.
One backlog also makes sprint planning easier. The focus of sprint planning is to bring together one set of priorities for an iteration based on items in the backlog. Most teams allocate a large portion of the iteration for new feature work. That’s normal and expected. Savvy teams have a strict definition of ‘done’ to prevent adding new technical debt, and have a iterative plan for reducing outstanding technical debt.
Quick filters make it easy to see how teams can prioritizes technical debt in context with other priorities especially during a sprint planning meeting. Just create a filter similar to:
type in (bug, x, y, z)
/* where x, y, z are other issue types that map to technical debt */
Then it’s easy to toggle between the entire backlog and highlight technical debt to ensure that the team has the right plan of action for the entire program. This also gives product managers and dev leads a gut check to make sure that the team is meeting technical debt goals for the short-term roadmap.
ProTip: Healthy engineering cultures effectively balance feature work and managing technical debt. In other words, it’s really important to create a culture where it’s ok to take time to fix technical debt as a collaborative effort with PM, by recognizing and rewarding engineering team members who do health work for the team.
Step 3: Enable creativity using 20% time and ShipIt!
At Atlassian, everyone has a desire to contribute beyond the cadence of our programs and as a company, we’re all about harnessing organic creativity. Three development engineers, Filip Rogaczewski and Arkadiusz Glowacki in Poland, and Andreas Knecht in Sydney, took advantage of 20% time and ShipIt to replace old technology with better performing technology for gadgets in Jira out of their personal desires to make the gadgets exceptional.
20% time allows Atlassians to innovate in new areas of their ecosystem 20% of their working time, and ShipIt is a quarterly competition for anyone to build or fix something that is:
- related to Atlassian products or processes
- can be completed and presented as a demo within 24 hours
- above all, fun
At the end of the 24 hours, everyone votes on their favorite projects (fun fact: we just celebrated 30 ShipIts!).
Ironically, Filip and Arkadiusz started fixing Jira gadgets in Poland while Andreas worked on the same project in Sydney through 20% time. They were connected when word got around that they had the same idea.
Next, all three engineers got together and decided to tackle the gadgets through 20% time and ShipIt. With the help of a Jira architect, the goal of the project was to address issues, mainly slowness, and overhaul all Jira gadgets. Up until this point, Jira gadgets were run on OpenSocial, a Google hosting environment that was popular in 2009, but has since been deprecated.
During ShipIt and 20% time, the new gadgets team came to the conclusion that the best way to modernize Jira gadgets was to redo each gadget individually and to release them incrementally in an agile fashion. This plan was low risk, not disruptive to the customer, and a perfect example of how to tackle technical debt. It was scalable, and over time, the team could see performance gains from Cloud dashboard load times to make sure that the new technology was working after ShipIt, and they were able to constantly improve the new gadgets.
That’s the value of harassing organic creativity – individuals can focus on areas of the product that deeply matter to them while making the entire product and codebase better, especially when tackling technical debt!
On a related note, now shipping!
We’re proud to announce that the team’s ShipIt project has now shipped! OnDemand customers, you’ve been auto upgraded. Jira Server customers, download the latest version here.