"Bug Team" for Legacy Systems

Legacy systems often have an equally large "defect backlog" - a list of well-known, relevant issues that need to be resolved at some point. The work of digging in old dirt is not fun. No developer enjoys doing this. Consequently, these defects tend to linger. But they do impede customer value, develpoment speed and sustainability. So - what to do?
A common solution is: "Let's make a bugfixing team."

Organizational role of the bugfixing team

The 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 good

The 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 bad

The bugfixing team may create an impression within the organization that "regular development teams" are absolved from delivering quality. 

Management and Scrum Masters/coaches must clearly communicate and emphasize at every opportunity that the bugfix team is dealing with existing impediments, but is not an excuse to shove "undone work" onto Production: There is no excuse for introducing "new bugs".

Developers on dedicated bugfixing team easily get frustrated: While other developers get to create fancy new stuff, they merely fix things which should have been working a long time ago already. Innovation potential on a bugfixing team is much lower.

Long term perspective

A bugfixing team should strive to "run out of work" as quickly as possible. The best state is reached when there are no important legacy bugs left to fix. The knowledge a bugfix team has obtained will be very valuable for the organization. After working in bugfixing for about half a year, developers possess a deep, intricate understanding of the system which other developers may not possess. 

This knowledge is very valuable to the organization: The bugfix team should be encouraged and motivated by the idea that the role is temporary and the entrance towards "something greater".

Summary

A bugfix team is not necessary in every organization. Management should state quickly that the main idea is getting out of the quagmire of Poor Quality and the institution is temporary. Developers must understand their responsibility is not "working off defects", but closing the manholes in the system, so they can move on as a team.

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.

Conclusion

If there is a clear business case for introducing a bugfixing team - by all means: at least consider the option. When moving forward - keep focused and provide perspective to bugfixing developers.