Unnecessary time spent on manual deployments: how Ops Run It denies you huge value (part 2)

Reducing time-to-market is proven to help digital organisations unlock enormous value. In the right circumstances, adopting You Build It You Run It—rather than Ops Run It—is the key to helping you deliver more value, faster.

Welcome to part two of this five-part series highlighting how a traditional Ops Run It operating model can deny you of value.

In a recent study conducted by Forrester, an organisation realised over $41 million of net-present value by improving time-to-market and reducing their ‘concept to cash’ timeline.

They achieved this result by adopting You Build It You Run It and moving away from the traditional Ops Run It operating model.

So, what is it about Ops Run It that prevents you from delivering valuable features at pace? Each piece of this series will look at a different aspect in detail.

The other parts of the series include:

• Part 1: Ops Run It prioritises stability in a way that fundamentally stops you from delivering at speed (which you can read here).
• Part 2: Ops Run It involves an unnecessarily laborious and manually intensive deployment pipeline (this article).
• Part 3: Ops Run It limits the agility of the development team, making it harder to respond to rapid changes in market conditions or evolving customer needs.
• Part 4: Ops Run It involves an overly strict change management process.
• Part 5: Ops Run It and potential impacts on resourcing for sustained innovation.

Ops Run It often involves an unnecessarily laborious and manually intensive deployment process.

This is largely caused by the fundamental structure of the teams in an Ops Run It approach.

There are at least two separate, siloed teams in Ops Run It. They are typically:

• The Delivery team: who focus on building software.
• The Operations team: who focus on approvals, change management, monitoring, and support.
• Sometimes, you may have a third team which is the team that does the deployment itself. This could be separate from either the delivery team or operations team.

In this approach, there’s a requirement for multiple handovers between the teams, which contributes to the complexity of the deployment pipeline.

This complexity can come to fruition in many ways.

In this piece, I’ll focus on testing and approvals processes prior to deployment.

Let’s analyse a practical example.

In Ops Run It, you’ll have a distinct subset team within Operations. Their role is solely to determine whether features are stable and ready for deployment.

The objective of this team is to assess and confirm that testing has been completed. This is typically a mandatory approvals gate as part of deployment.

Critically, this change management team is not involved in building software.  Nor are they involved in identifying which features should be built.

As a result, change management teams typically resort to relying on a testing checklist to carry out their role.

For every change or deployment, they will ask:

• Has the unit testing been completed?
• Have the acceptance tests been completed?
• Have the performance tests been completed?
• Have you done a penetration test?
• Where is the evidence of these tests?

The better, more valuable question—rather than ‘have you completed X test?’—is ‘have you completed the right tests with the right amount of testing on the right portions of code? Are the right tests in place for the features that are being developed.’

For example, teams will be able to confirm they’ve tested for specific scenarios and alternative scenarios. They will be able to confirm testing in a specific area of the system where changes have occurred and where there are downstream dependencies.

And the only people who will know the answer to that question are the delivery team who’ve built the software.

You Build It You Run It can eliminate these inefficient, bureaucratic approvals processes.

In You Build It You Run It, the team who builds the software is the team who then runs and supports that software in production.

As a result, teams in this model will conduct multiple rounds of incremental tests themselves. They are motivated to ensure the code is highly available because they have to support it in production.

For example, teams in You Build It You Run It will commonly:

• Provision automated unit testing that can be run at any time to ensure that the unit of code that has changed now does what it is supposed to do.
• Provision automated  acceptance-based testing to ensure the features meet the acceptance of the users and business
• Provision automated load and performance tests that can ensure that the system can cope with different volume requirements.
• Provision automated security tests that can ensure that the system is secure.

The reason teams will do this is because You Build It You Run It teams are likely to automate their deployment pipleine, so that every change they make is repeatable, reliable, and quick to action.

Without automating all these tests, teams can’t automate their entire pipeline. As a result, manual testing will need to take its place.

When the one team builds and scrutinises their own code to ensure it is highly available—because they’ll be responsible if there are failures in production—there is no need for multiple manual approvals gates in deployment.

In this scenario, there is no need to have time-consuming checkpoints or change management processes prior to approvals for deployment to production because that checklist has been built into the deployment pipeline. With ineffective approvals meetings replaced by an automated pipeline and testing, the deployment process is simplified and, importantly, repeatable and reliable. There is less time spent on handover and a reduced requirement for approvals milestones, but with the same emphasis on QA and rigorous code assessment.

Ultimately, you get the same quality code—or higher—in a much shorter time frame.

Through this approach, we’ve supported clients to improve their deployment throughput from 10 releases per year to over 4,000. Without a correlating rise in production incidents.

While You Build It You Run It can be incredibly potent, it’s worth acknowledging that Ops Run It is still a valid operating model.

The right operating model will depend on the needs of the service; in instances where speed-to-market is critical, You Build It You Run It will typically unlock significant value.

For more information on selecting the right operating model, you can:

• read about selection processes in our You Build It You Run It playbook, or
• read this piece; two things to consider when selecting an operating model for a digital service.

If you’d like to discuss your implementation of Ops Run It, You Build It You Run It or any of the challenges you face in delivering features at speed, I’d love to help.

Are you sitting on a substantial amount of net-present value waiting to be unlocked? Let’s arrange a conversation to find out.

If you haven’t read it yet, check out or first part in this series on how Ops Run It stops speed & denies you value.