Should the PO be responsible for bug management?

If a bug was found during a sprint - Unless your company has specific guidance on fixing bugs, they represent work to be done and should be ordered on the Product Backlog by the PO. Two exceptions are if the work to fix the bug is less than the work to actually log it, or if the bug is so critical that it would be negligent to leave it unfixed.

The PO and Developers could monitor the following key value metrics from the Ability to Innovate key value area: 

Defect Trends:  Measurement of change in defects since last measurement. A defect is anything that reduces the value of the product to a customer, user, or to the organization itself. Defects are generally things that don’t work as intended.

Technical Debt:  A concept in programming that reflects the extra development and testing work that arises when “quick and dirty” solutions result in later remediation. It creates an undesirable impact on the delivery of value and an avoidable

increase in waste and risk.

Production Incident Count:  The number of times in a given period that the Development Team was interrupted to fix a problem in an installed product. The number and frequency of Production Incidents can help indicate the stability of the

product.

Change Failure Rate:  The percentage of released product changes that result in degraded service and require remediation (e.g. hotfix, rollback, patch). For more information, see the DORA 2019 report.

For bug fixes, the responsibility changes depending on where the defect was found.

If defects are found during the Sprint in which the work is being done, then the Developers are responsible for fixing the defects and getting the work to meet the team's Definition of Done. If there needs to be a tradeoff between meeting the Sprint Goal and release with known defects, then the Developers may want to consult the Product Owner to understand if it's better to not release or release with known defects to get fast feedback.

If defects are found on work that the team has already completed, the Product Owner would be accountable for ordering the work on the Product Backlog. This could also include interrupting the current Sprint to attempt to resolve an issue earlier. The Developers would be involved in refining the reports, which may help the Product Owner properly order them.

Monitoring bug trends doesn't fall to anyone in particular. My suggestion would be that the Scrum Master is in a place to help the team understand what data they have and what they may need to start collecting to be able to answer questions about trends in product quality. The Scrum Master would also be in a place to help the team and external stakeholders figure out what trends would add value to a decision-making process. However, the actual data collection and monitoring may involve any person on the team.

RCAs should be facilitated by the Scrum Master. Since RCAs attempt to get to the root cause, the Product Owner and Developers should be involved in determining the causes, identifying the root cause, and coming up with a plan to prevent future occurrences. In my experience, it's very difficult to participate in an event while also facilitating it. If the team has someone splitting their time between Developer and Scrum Master, it may be a good idea to find an outside facilitator. I'd apply the same suggestions to Sprint Retrospectives, as well.

Who is responsible for monitoring bug trends, scheduling bug fixes, RCAing bugs?

If work is not Done the Developers will be accountable for fixing it and assuring quality. Others may undertake certain responsibilities for doing so. The Product Owner may triage repairs on the Product Backlog for example.

- The Scrum Guide states that the PO is accountable for "Ordering Product Backlog items". PBI's are not only User Stories, they could be whatever the team deems convenient as, for instance use cases, test cases, improvements, maintenance tasks... and, yes bugs.

- But the Scrum Guide also adds "The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable". As you see there is flexibility on how to manage aspects like bug prioritization depending on what is the more suitable scenario based on the team's context.

- In the case of defect monitoring, the whole Scrum Team is accountable on bringing transparency about what is the current situation of the product. If there is not enough transparency, the Scrum Master must issue this fact to the whole Scrum Team in order to solve it.

- On RCA for bugs, the SM has also a paramount role to facilitate on how to arrive to that root causes.

Hope these answers will be of any help, Niall!

Thank you all, this answers my questions.



Another caveat is the Bug management in a scaled environment e.g. 12 teams, 8 SMs. 

Any idea how this would work with the above?

There is a list of Bugs, still unknown which teams should own them, more triaging required, RCA is also an issue i.e. which SM would drive RCA on which Bugs.

Bug trends across the product is increasing but no one seems interested in finding out why and if and how to fix it.

I'm going to repeat a response that I use for a lot of the questions here.   The Scrum Team should decide how this is going to be handled.  

I have yet to meet a developer that didn't want to fix defects.  However, they will also be reasonable in the assessment.  They will be forward with their explanation of whether this defect has to be fixed now or could be fixed later.  If given enough information about the business criticality and dependence of the features on which they work, I have found that they make very good decisions.  

I will also say that I define a defect as something that has been released to production.  If an issue is found during the development and is caused by the new development, I don't count that as a defect. It is work done improperly.  There are times that improperly done work could be released and fixed later. But as I said, the developers will usually want to fix that as soon as it is found.  Defects are something that made it into production, whether it was known or not.  At that point every defect is work that is needed to improve the product. The Scrum Guide states this about the Product Backlog

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

I expect you know the rest of what I would type.