A common solution is: "Let's make a bugfixing team."
Organizational role of the bugfixing teamThe bugfixing team may have directly or indirectly measurable targets, typically a reduction.Targetted metrics may include, for instance, defect count, defect cycle time, technical debt, customer complaints, waste incurred by sighting [customer] problems, unplanned system outages, release delay etc.
Their value lies in the reduction of ongoing loss. At the same time, theyprevent of further loss.
From a technical perspective, the bugfixing team is a development team like any other. They work with backlog items and bring them towards meeting a Definition of Done. To achieve this, they elaborate Acceptance Criteria, work on the source code, verify solutions, produce and deploy builds.
Why a bugfixing team is goodThe elephant in the room finally disappears: Something is happening.
The introduction of a bugfixing team is a clear signal from management that Quality is being taken serious.
A dedicated bugfixing team has much better levers than regular development teams of not only "fixing the symptom", but digging all the way down to the root cause.
At best, the bugfixing teams gain intricate knowledge about what makes the system click and tick - where the risks, threats and opportunities are. This knowledge is very valuable not only in solving bugs, but in sustaining the current (legacy) platform and potentially in the introduction of a new platform in the future.
A bugfixing team has no choice other than working as a "feature team", because bugs are hardly limited to individual components - although they typically cluster. In this way, bugfixing teams are a way of successfully introducing the idea of feature teams in an organization.
Why a bugfixing team is badThe bugfixing team may create an impression within the organization that "regular development teams" are absolved from delivering quality.
Long term perspective
The Product Owner in charge of the bugfixing team should prefer "defect areas" over small-scoped, local problems, although these provide quick-wins.
The Scrum Master working with the bugfixing team must harp constantly on the "Continuous Improvment" of the system, the team and the organization. Only by focussing on Continuous Improvement will the team overcome the unsatisfactory treadmill of fixing an endless flow of reported defects.
A potential solution to prevent developers from feeling stuck in "bugfix mode" is to rotate the "bugfixing team" in the organization every few months.
Management and PO must keenly observe when the point is reached where the loss associated with existing defects turns the team into a negative business case. At that point, the team should stop being a "bugfixing team" and take on more valuable feature development activity.