Problem
With the best intentions not to release anything that doesn't meet the highest standards of quality, the pressure of speedy delivery and the realities of imperfect humans and circumstances can mean we build up technical debt which over time causes the code to be more difficult to maintain, the application to seem slower to end users, the company to be vulnerable to security breaches, and so on.
Solution
Expose it
Create tasks in your task & issue management system. Some teams wait to be given permission by management or product owners to handle technical debt and when they eventually get their way, they have no tasks ready to go. Create the tasks. If a team isn't coming up with enough initiatives, find out what's holding them back. Is it lack of time? Is it lack of expertise? Is it lack of analytical tools? Find out & address it.
Promote it
There is or should be a healthy push and pull in agile development teams between developers and the product owner when it comes to what goes into a sprint. The team picks the tickets, but the product owner should protest if what's being pulled in is out of touch with the product roadmap. The product owner can protest, but the team must stand up for quality. If either side is too shy, you'll end up delivering insufficiently valuable work or insufficient valuable work.
Protect it
Even during a sprint, external pressures can mean work on technical debt tasks is halted or delayed in favour of more urgent feature work. In theory, a team should be assertive enough to protect against the inevitable eroding of technical debt work. In practice it means persuasive "just this time" requests. To prevent this, get buy-in from the highest levels of the organisation, demonstrate to them the importance of working on technical debt in their language (ROI) and explicitly agree with them a % margin in each sprint that teams can dedicate to it, as otherwise the long term benefit of moving fast safely can't compete with the more immediate benefits of feature delivery until it's too late.
Spread it
Some organisations get so fed up with technical debt, they decide to dedicate 1 or 2 sprints solely to paying off technical debt. This doesn't work. First, you lose momentum on feature work and there will be pressure to make up for it. Second, the technical debt might be heavy on a particular specialty (such as backend). Third, you will just have to do it again after a few months. You'll want to keep momentum on both feature work and technical debt. Spread it out and keep up on your repayments.