What worked for us, wasn't convincing managers to take on a full scale refactoring project. Rather, we agreed to create a User Story named "Tech Debt", and added work items to it as we discovered the "bugs". We were able to get this agreement due to the pressure of getting other stories done in compressed schedules, but having to trip over the bad stuff over and over again.
Without a collection of items spelling out tech debt, managers don't see it.
Outcome
Unfortunately for us, each sprint planning session ignored the tech debt items, simply because the business had other higher priority items. After about four months of this, we realized Tech Debt never floated to the top.
"We would make sure the new and old code was fully tested (using automation)". This was the key to success. We all agreed that even one line of code change is potentially dangerous.
Become the Best Tester in your Department
My advice would be to become one of the best test creators in your organization. Let the tests speak for themselves by creating bugs you find, so it will show up on the daily scrum work board.
Managers and Scrum leaders don't like bugs! Many of them feel they should only be created when found in production, but that attitude is how tech debt grows, lack of visualizing Bugs means they don't exist. Bugs should be created whenever a bug exists, even in dev after a sprint. The bug queue is really our best friend, as it is a catalog of the current functionality of our product. So what, if the bug backlog is large, at least it's visible and planning can occur.
Who let the Tech Debt in, and why is it still here?
Tech Debt is a manifestation of a much larger, environmental issue. It's everywhere, starting on the very first line of code, it's like a toxic mold, which requires a lot of effort to remove. Without removal, the product simple dies a slow death. Managers must recognize tech debt.
Be Careful
Be very careful to always maintain a positive attitude towards this effort. Reason: The managers who are there now may have been the ones that approved the architecture that created the "tech debt". They may be interested in hearing about the effects of their decisions 5 years ago, but most will not. Especially when it cost the company a lot of money to bring in someone that did the work in the first place.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Be Careful calling out Tech Debt
What worked for us, wasn't convincing managers to take on a full scale refactoring project. Rather, we agreed to create a User Story named "Tech Debt", and added work items to it as we discovered the "bugs". We were able to get this agreement due to the pressure of getting other stories done in compressed schedules, but having to trip over the bad stuff over and over again.
Without a collection of items spelling out tech debt, managers don't see it.
Outcome
Unfortunately for us, each sprint planning session ignored the tech debt items, simply because the business had other higher priority items. After about four months of this, we realized Tech Debt never floated to the top.
How to Approach Tech Debt
Our own solution was:
"Any time we opened the code, we agreed to refactor to make it better, but only for a narrow limited scope ".
"We would make sure the new and old code was fully tested (using automation)". This was the key to success. We all agreed that even one line of code change is potentially dangerous.
Become the Best Tester in your Department
My advice would be to become one of the best test creators in your organization. Let the tests speak for themselves by creating bugs you find, so it will show up on the daily scrum work board.
Managers and Scrum leaders don't like bugs! Many of them feel they should only be created when found in production, but that attitude is how tech debt grows, lack of visualizing Bugs means they don't exist. Bugs should be created whenever a bug exists, even in dev after a sprint. The bug queue is really our best friend, as it is a catalog of the current functionality of our product. So what, if the bug backlog is large, at least it's visible and planning can occur.
Who let the Tech Debt in, and why is it still here?
Tech Debt is a manifestation of a much larger, environmental issue. It's everywhere, starting on the very first line of code, it's like a toxic mold, which requires a lot of effort to remove. Without removal, the product simple dies a slow death. Managers must recognize tech debt.
Be Careful
Be very careful to always maintain a positive attitude towards this effort. Reason: The managers who are there now may have been the ones that approved the architecture that created the "tech debt". They may be interested in hearing about the effects of their decisions 5 years ago, but most will not. Especially when it cost the company a lot of money to bring in someone that did the work in the first place.