Any team that doesn’t prioritise fixing defects over building new features is doomed. [Ok that’s hyperbole]
The Andon principle is there for a reason. Higher quality now means less unplanned work in future which increases velocity.
Likewise any team that doesn’t prioritise improving work over doing work: you’ll be doing it the same crappy way next year.
I thought these principles were well understood in the Agile community.
The product backlog should include all work: features, defects, improvements, maintenance. If you are using Scrum, then new production defects should go in the sprint backlog as well as the product backlog. (… Alternatively I suppose a defect can go in the product backlog if the processes are such that the Team are immediately aware of it and can urgently have a discussion with the product owner(s) to pull it immediately if necessary.) We need to triage immediately to decide that. A defect can be quietly corrupting data. The impact is not obvious to anyone but a developer.
The greatest weakness of Scrum is the multi-week batching of work, which can only be explained when we realise it assumes only new development is being done and somebody else is fixing production, i.e. a project-oriented methodology. If you don’t engineer your Scrum method to prioritise production defects over features, and to handle them as normal work not exceptional interruptions to the sacred Sprint Goal, you can never have product teams instead of project teams.
If an Agile team were truly autonomous and self-organising, then it would be on the team. But of course they seldom are. They’re driven to focus on features while still being held accountable for quality. It’s not just a lack of management support, it’s the wrong kind of managing.