You need to flip the script on the problem. It's no longer a technical problem, it's a management problem.
Management problems are solved with spreadsheets that show concrete numbers going up or down.
At the beginning of each sprint ask the manager what % of time developers should spend fixing quality issues on each story after the story is complete. 0%? 30%? 50%? Track it. Graph it.
At the end of the sprint ask developers "how do you feel about the quality of the code base this sprint? [ 0 dangerously unstable --- 100 - clean and perfect ]. Track it and graph it.
Track what % of stories in the sprint are "code quality" stories (e.g. upgrade node). Create a graph showing four consecutive sprints with 0% time allocated to code quality stories.
After about 4 sprints of this, provided you were reasonably open and transparent about what you were doing, you'll probably have a slightly freaked out product manager who is newly cognizant of the need to properly allocate time to "quality".
If it turns out he's an idiot who ignored your little game, well, you've amassed documentation necessary to make his bosses start considering his termination and replacement.
Don't fuck around with this stuff though - you can invite all sorts of problems if you're not careful with this approach. Assume everybody is honest and has good intent until proven otherwise.
Management problems are solved with spreadsheets that show concrete numbers going up or down.
At the beginning of each sprint ask the manager what % of time developers should spend fixing quality issues on each story after the story is complete. 0%? 30%? 50%? Track it. Graph it.
At the end of the sprint ask developers "how do you feel about the quality of the code base this sprint? [ 0 dangerously unstable --- 100 - clean and perfect ]. Track it and graph it.
Track what % of stories in the sprint are "code quality" stories (e.g. upgrade node). Create a graph showing four consecutive sprints with 0% time allocated to code quality stories.
After about 4 sprints of this, provided you were reasonably open and transparent about what you were doing, you'll probably have a slightly freaked out product manager who is newly cognizant of the need to properly allocate time to "quality".
If it turns out he's an idiot who ignored your little game, well, you've amassed documentation necessary to make his bosses start considering his termination and replacement.
Don't fuck around with this stuff though - you can invite all sorts of problems if you're not careful with this approach. Assume everybody is honest and has good intent until proven otherwise.