The honest answer to this question is more distributed, and less satisfying as a soundbite, than most organizations want it to be. Scrum's accountability structure spreads responsibility for performance across the whole team in a way that resists the instinct to name a single owner, and understanding why clarifies a lot of confusion that arises when performance issues actually surface.
Why there's no single answer
The Scrum Guide's three accountabilities are each responsible for a different dimension of performance. The Developers are accountable for the technical quality and completion of the work: whether what gets built actually meets the Definition of Done. The Product Owner is accountable for value: whether the team is working on the right things in the right order to maximize what the product delivers. The Scrum Master is accountable for effectiveness: whether the team's practices, environment, and organizational context allow it to perform well at all.
A team can fail on any one of these dimensions while succeeding on the others: technically excellent work built in the wrong priority order (a Product Owner accountability gap), or the right priorities pursued through a dysfunctional process that burns the team out (a Scrum Master accountability gap), or good priorities and good process undermined by inconsistent technical quality (a Developer accountability gap).
Why organizations keep looking for a single name anyway
Traditional management structures are built around individual accountability (one manager owns a team's output, full stop) and it's a natural instinct to look for the Scrum equivalent. The instinct is understandable and the framework genuinely doesn't work that way, which creates real friction in organizations transitioning from a traditional structure, where stakeholders keep asking "who do I hold accountable" and the honest answer requires more explanation than they're often looking for.
What performance conversations should actually look like
Diagnosing a performance issue well means identifying which of the three dimensions is actually the problem before assigning any kind of ownership for fixing it. A team that's consistently missing its Sprint Goals might have a Product Owner problem (poorly defined goals, unclear priorities), a Scrum Master problem (unaddressed impediments, dysfunctional team dynamics), or a Developer problem (skill gaps, unrealistic self-assessment of capacity), and the fix looks completely different depending on which it actually is.
Organizations that skip this diagnosis and simply hold "the team" collectively responsible for every performance issue, regardless of its actual source, tend to apply the wrong intervention more often than not: coaching Developers on estimation when the real problem is a Product Owner setting unrealistic expectations, for instance, doesn't fix anything, because it's addressing the wrong accountability for the actual gap.
The Scrum framework's answer to "who's responsible" isn't evasive. It's precise about exactly which accountability owns which dimension of performance: the difficulty is that precision requires more nuance than a single name, and organizations used to single-owner accountability structures often resist that nuance longer than they should.