In a Scrum shop who calls the deployment?

Question

Imagine a Scrum team with a canonical sprint of 2 weeks. The product could be anything - backend, frontend, mobile, PC game etc.

The devs write code and unit test it. So each knows their end of the woods but no one has the broader perspective.

The QAs observe metrics on automated tests, A/B tests, support calls, task completion statistics - but they too are engineers, not business people.

The PO knows about the business goals but they do not understand the technical aspects of "BUG X".

So how should a roll-out happen in a sane organization? Who approves it; based on input from whom? Do they use their private keys to deploy or do they write an e-mail to engineering "OK, do it"?

Bonus question: how should a roll-back happen?

_{Creating tag release. Perhaps it is not needed; perhaps the whole question is better off migrated to another SE.}

Answer 1

Generally, it's a project management plan which has the timeline for the deployment. As long as the person or the team is concerned, it's either the DevOps (hosted) or the Service/Customer Experience team (on-premise) handles the deployment. There's no hard and fast rule, but in my experience that's the arrangement in many of the product organizations.

To elaborate, the scrum works towards completing features which contribute to a "Milestone" (can also be referred to as a "release" candidate). In the roadmap, the individual work items are mentioned and mapped to that release, so as the work is done, the completion status / percentage is updated. Other than Dev and QA, there are other components as part of the roadmap, like Scale/Load/Performance testing, Security/vulnerability Checks, Licensing checks, Legal and compliance checks, and once all these checks are passed and final release build is generated, it is tagged with "GA" (or generally available) build.

Then, based on the arrangement,

• either the DevOps team start the deployment process and take care of provisioning the instance, so that the service is up and running and accessible to the end users, or,
• the builds are handed over to the Service management / Customer Experience team, which then co-ordinates with Customer SPoCs to find out a slot for the deployment / upgrade of the application/service.

To answer "How should a roll-back happen?": That is a defined process for update of any existing / running version, and usually accomplished by creating and following a MoP for the process. The same team in charge of deployment, can take care of the rollback, as and when needed.

Answer 2

I think you have some misconception about Scrum

So each knows their end of the woods but no one has the broader perspective.

In this case you don't have a team, you have a collection of people working on the same software. In Scrum the team work implements sprint goals to achieve a product goal each a broader perspective than a task

The QAs observe metrics on automated tests, A/B tests, support calls, task completion statistics - but they too are engineers, not business people.

Support calls, at least nature and volume, and task completion statistic should also be checked by the PO, which is a business role.

The PO knows about the business goals but they do not understand the technical aspects of "BUG X".

Do they truly understand the business if they don't understand how BUG X affect the business? The technical aspect is a business aspect, at least in difficulty and effort to solve. The technical details however should be entrusted to developer and the PO have trust in them (and developers need to earn and keep this trust)

So how should a roll-out happen in a sane organization? Who approves it; based on input from whom? Do they use their private keys to deploy or do they write an e-mail to engineering "OK, do it"?

It depends of the organization and functional context. "Sane" in finance and trading is not the same as e-commerce. Ideally it would be no-one. It just rolls out when it's ready because you have automated everything possible and you just eventually have people with different role/credential to validate some steps. Sometimes you can roll out when a developer click on "push" for it's code. Sometimes there are marketing campaign and you want to hold until a release date.

Bonus question: how should a roll-back happen?

It depends. Either easily or painfully. E-commerce you can roll back a commit and push to prod. A bug in automobile software you have to recall all vehicle or at least have them sent to a workshop for software update.