In a scaled environment, who is accountable for releasing product regularly?

Deciding when to release is a collaborative effort. In Scrum-based frameworks, the Product Owner remains accountable for maximizing the value of the work done by the Scrum Team(s) working on the product. But the Product Owner wouldn't just pick a number. Optimizing your processes and workflow to release faster than your downstream stakeholders can accept is wasteful. Technical debt, the development practices, and the tools used can make it difficult to release faster. The Product Owner should understand what the appropriate release cadence is and the team - with coaching from the Scrum Master - should work to get there. There's also a consideration of how quickly the team can release. Being able to release certain things faster, such as responding to defects, vulnerabilities, or incidents, when necessary is also important.

What scaling framework are you using? Nexus offers the Nexus Integration Team. Since this team is accountable for the Nexus producing a done and integrated Increment each Sprint and has a Product Owner, Scrum Masters, and appropriate members from the Scrum Teams in the Nexus, this is the right place to have those discussions about release frequency (among other things). LeSS, on the other hand, promotes more ad-hoc and just-in-time coordination, so these discussions would tend to happen around Sprint Review (with stakeholders) and the Overall Retrospective (among the members of the teams).

If you need to improve your ability to release and deploy, product changes (such as technical debt paydown) would go onto the Product Backlog and process improvements would be handled the same way your Sprint Retrospective improvements are managed. The Product Owner would need to order the Product Backlog and the team would have to discuss capacity and the scope of commitments (the Sprint Goal) to be able to make the product and process improvements needed to change the release cadence while maintaining product quality.

Very good. 

The cadence has been left in the hands of the PO and the balance between what the customer needs and the tech debt to get their has been somewhat balanced.

There could be a question here now whether the SM and others should push for more frequent deliveries. There is an case that one of the reasons product may not wish to deliver more frequently because they do not wish to spend time addressing the tech debt and issues preventing frequent delivery. This could be seen as the responsibility of the SM and others to get addressed even if the PO wants features features features.

I don't think that the Scrum Master should be pushing on their own, no. Whether it's routine delivery or response to more critical issues (defects, vulnerabilities, incidents), it's up to the stakeholders to define how long they are willing to wait for the delivery. Then, the Scrum Master can work with both the stakeholders and the team on product and process improvements as well as managing expectations. The accountability for making the decision on the value of produce enhancements and if improving delivery cadence is valuable lies exclusively with the Product Owner, but ideally in consultation and discussion with the rest of the Scrum Team.

I agree. Many thanks. 

Who is accountable for releasing product regularly?

The Developers, because they are accountable for getting work to Done. Once a Done Increment has been produced, the imperative is to then release it. That's how empiricism is maintained.

Team members, including the Product Owner, can stop a release from happening, if it is no longer seen as the right thing to do.

What if the PO does not agree because the effort to release is so time consuming and would prefer the devs to spend their time developing (and not releasing to production) ? 

Something to consider is that there is no value in development until such time that it is released and put into customers hands. Until the point of releasing it is expense and inventory. It is also very risky as no feedback is being gained and there is no validation of assumptions.

A PO ought to consider the total cost of ownership for the product which includes investments in optimizing the value delivery flow to customers and paying back technical debt. 

Niall is bringing up a good point with effort to release.

There are a few concepts to keep in mind:

• Stakeholders are "individuals or organizations that have a right, share, claim, or interest in a system".
• Customers are "organizations or people that receive a product or service".
• Customers may be internal or external. The development team is never a customer as they are creating and maintaining the product, not receiving it. The development team is, however, a stakeholder.
• There are many definitions for release. Most are about making a particular version or set of changes available for a specific purpose. Some definitions explicitly call out availability to customer.
• Release management is about "managing the activities surrounding the release of one or more versions of software to one or more customers".

I fundamentally disagree with the notion that you need to release to maintain empiricism or get feedback. If you do not make the product available for customers for their purposes or processes, you are not releasing. Perhaps it's splitting hairs, but I don't consider a demonstration environment that exists only to allow feedback to a development team to be releasing. Releasing would be allowing the product to go through a system integration process or user acceptance testing or even production usage - some activity or process that is not owned and managed by the development team.

It is far more important to get feedback and handle that feedback than it is to release. Then, you release when it makes sense to, based on effort or cost or schedule. After getting feedback, the ability to have something to release on demand that addresses stakeholder feedback, maintains the desired level of quality, and is useful and valuable is more important than actually releasing.

Perhaps this is my background in more regulated environments talking, but failure to consider these types of environments and treating everything like a business software application has done a lot of harm to the adoption of lean and agile methods in other contexts where they would be extremely beneficial.

What if the PO does not agree because the effort to release is so time consuming and would prefer the devs to spend their time developing (and not releasing to production) ? 

Regardless of what anyone else prefers, the Developers are accountable for producing at least one Done Increment of immediately usable quality every Sprint. That's how empiricism is established and maintained, and no-one can obligate them to do otherwise.

If the Product Owner is trying to do so, then you have an additional problem, in so far as he or she appears to have lost the plot about the need for empiricism, and the need to obtain real-world Product feedback each Sprint.

Release of course does not necessarily have to be into production, but it does have to be into an environment which is empirically fit for purpose, such as a representative cohort of users for example.

I like the differentiation between release and getting feedback. A staging area could be a workaround for us, we actually have one.

Of course the underlying issue with the tech debt and that reasons why we do not deliver to production more often is still a concern. I would love to shake this out and push for delivery each week in order to bring the tech debt to the surface but that is a decision for the PO.