When it comes to managing the release cadence, a business really only has three choices, regardless of industry or framework:
- Fully integrate QA with development.
- Accept that either developers or testers will be idle some part of each Sprint when practicing Scrummerfall.
- Decouple releases from delivery or deployment (more on that below).
While high-compliance environments aren't orthogonal to agility, the demands of the compliance requirements can sometimes force a business to face the fact that you can't have disparate processes that move at different speeds run in lockstep. High-compliance environments also tend to fall prey to the 100% utilization fallacy, so the idea of having sufficient slack in the process to allow disparate processes to deploy on the same cadence is unrealistic.
Decoupling, when supported by the right engineering and process controls, is usually the sanity-preserving way out.
Differentiate "Delivery" from Deployments and Releases
While it's generally best to integrate QA directly into your Sprints, a lot of businesses overlook the value of decoupling delivery and deployment from release. While Scrum mandates that the output of a Sprint is a potentially-shippable increment, it doesn't actually require that the increment be released to end-users.
In a regulated environment, agile teams are still responsible for delivering increments that meet the Definition of Done. However, downstream processes such as third-party testing or production releases do not have to move in lock-step with the development team.
The main issues you are likely to face with decoupling deliveries from your other processes are: the need to negotiate bug-fixing with the business, and the assignment of responsibility for releases outside of the Scrum team.
In canonical Scrum, bugs found outside the development cycle must re-enter the Product Backlog. The business contracts with the Scrum team not to bypass the backlog and estimation process, although early terminations (costly as they are) certainly remain an option.
Furthermore, a truly decoupled release plan means QA or some other team will own the release. Whether the business tries (and likely fails) to have every delivered increment tested and released, or whether they more sensibly give the release teams the authority to batch up deliveries and set their own cadence for tagging and deploying releases is strictly a management decision.
There are certainly variations on these themes, but the core tenet is that each Sprint must maintain its integrity against unplanned work, and that any work moved outside the team must abide by that. So long as that's true, decoupling releases is the approach I advocate in healthcare and government settings.