Don’t let them deploy to their Staging environment. (1) Make them present their product to a VP for software maturity approval. (2) Then make them ask permission from the local change approval board. It doesn’t matter whether they approve, because you’ll (3) make them seek additional permission from the global change approval board. Ask for proof that all of their customers formally signed off; never mind that their customers run their own bureaucracies and can’t tell you who is authorized to approve. (4) Finally, make them get permission from the global Ops approval board. It doesn’t matter that the team practices DevOps, and that their Ops team is integrated into their Dev team–the global Ops approval board needs to rationalize their existence.
All that just to deploy in Staging, simply to rehearse Production deployment.
(5-8) Repeat these four formal approval gates for Production deployment. Ignore the fact that your high performance agile team knows what it’s doing and does it well. Just make them jump through the hoops. Eventually they’ll get tired, stop fighting it, and slow down. They’ll bow to your pressure and stop their frequent delivery of new value to their customers.
Instead of handcuffing your high performance agile team, how about helping them deliver value to their customers? Try asking them for one concise formal statement of readiness. They already produce it as part of their Definition of Done.
Nominate a single person from Dev and a single person from Ops to be responsible for deciding whether the product is ready for Staging or Production deployment. These guys cares about getting it right–they get fired if the team deploys something that sucks, something that yields downtime for their service or for their customers’ services.
The DevOps team wants to be great. Champion their cause, don’t get in the way. Help them deliver value to their customers.