Change-management that actually stifles change: how Ops Run It denies you huge value (part 4).

Slow moving approvals. A change-management process that takes so long the change is no longer relevant when it’s delivered. Sound familiar?

This wreaks havoc on your ability to innovate at pace. And as a result, denies you from capitalising on the huge potential that exists within your organisation.

And there can be huge potential.

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 moving to the You Build It You Run It operating model and implementing paved roads.

If you’re currently working in a traditional Ops Run It model—where teams are segmented by responsibility into ‘Delivery’ and ‘Operations’—you could be sitting on comparable mountains of untapped profit.

In this article series, I’ve been highlighting how and why that’s the case:

• 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 (which you can read here).
• 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 (which you can read here).
• Part 4: Ops Run It involves an overly strict change management process (this article).
• Part 5: Ops Run It and potential impacts on resourcing for sustained innovation.

Ops Run It involves an overly strict change management process, which causes delays for releases and costs you in unrealised value.

In Ops Run It, you have your Delivery team. They build the software.

Once a new feature is built, they hand off to a second team—effectively a change management function for the business—before that team assesses the feature for approval to production.

Once approved, often the feature is pushed to a third team, which is your Application Support team. They’re responsible for releasing things into the production environment. In some organisations, this same feature can then be pushed to a fourth team, which is responsible for the incident management and running of the service.

In an Ops Run It operating model, any new feature will move linearly through the teams outlined in the above diagram, from left to right.

If we look at the inherent motivations of these teams, we can assume that:

• The Delivery team is incentivised to deliver: they want to build as many features as possible.
• The change management function within Operations is incentivised to safeguard against problematic deployments: they want to minimise any downtime caused by deployment to production.
• The Operations team is incentivised to maintain a high level of availability.

We can see that two of the teams are primarily motivated by the availability of the system, not by the delivery of new, valuable features.

Both the change management team and the Operations team will likely:

1. Have a natural aversion to updating the system.
2. Have availability targets to meet.

They’re not judged on how many valuable or innovative features are delivered, which is problematic for both you and your customers.

To protect against compromising their availability KPIs, the teams will implement time-consuming change management processes.

One example is the Change Acceptance Board, or CAB.

Teams will typically attend these meetings to run through a perfunctory checklist, spending time to tick off a checklist of testing requirements.

Change Advisory Boards are not the problem. But they’re certainly not the solution either.

CAB meetings are often implemented as a strategy to mitigate risk. In certain regulatory environments, there’s also a common requirement for ‘separation of duties’. Or, the need for more than one development team to assess code before it’s pushed to production.

Organisations will immediately implement CAB meetings in response to this requirement because there’s a clear delineation between Delivery and Operations.

But as we’ve established, the handoffs required between distinct segmented teams are slow and time consuming. And these bureaucratic gates prevent you from innovating rapidly at scale.

With You Build It You Run It, there’s a better way.

You can still maintain separation of duties in You Build It You Run It.

In You Build It You Run It, there are no handoffs between teams. Because the team that builds the software is responsible for the operation and support of that software.

This eliminates the need for handoff and approvals processes like CABs. But the question remains: how do we accommodate for separation of duties with a single team?

There are three main techniques. You can implement all of them in conjunction.

1. You can carry out Extreme Programming (XP) practices like pair programming and continuous integration.  These practices involve more than one person, which means code is being assessed by multiple developers throughout the development pipeline.
2. You write automation tests. These automation tests should be written as the team’s first port of call and vetted and validated by external stakeholders. From that point on, all subsequent code is written to match the requirements of the automation tests. This provides objective, third-party validated proof that the code is highly available prior to deployment.
3. You engage a Platform team to build a paved road for you.

A paved road is officially defined as “a low friction, hardened interface that comprises user journeys, where the user is the product delivery team.” Let’s break that definition down.

Low friction = easy to use.

Hardened = proven and reliable.

Interface = communication between the developers’ code and the infrastructure that supports it.

User journeys = the developers’ or organisational processes required to build, deploy, run, and operate a service.

Examples of paved roads can include automated deployment processes and service alerts.

What’s the purpose of a paved road? How does it relate to separation of duties?

Paved roads are designed to abstract complexity away from common daily operations and eliminate unnecessary cognitive overload. They allow the product delivery team to focus on delivering value.

A Platform Team will manage all paved roads for the organisation, which multiple teams can draw from.

In the context of separation of duties, when you have a paved road that automates deployment, it’s the Platform Team who builds the capability to deploy, not the product delivery team themselves.

This ensures a clear separation of duty. The Platform Team will have implemented all necessary checks and balances—and encompassed the learned best-practices specific to your organisation—in building out the deployment process.

When you’ve validated all your paved roads, which will be replicated exactly through automation whenever they’re required, there’s no need for time-consuming change management or approvals functions like CAB meetings.

Your team is freed up with additional time to focus on:

• Understanding the features your customers want and need.
• Building and deploying those features.
• Learning how customers use what they’ve built.
• Repeating the process rapidly to deliver far more value in a much shorter time window.

Are you delivering valuable change? Or are you caught up in ineffective change-management cycles?

If you’re hampered by slow moving approvals processes, you could be sitting on mountains of untapped net-present value.

And I can help you unlock it for your organisation. If you’re interested, let’s arrange a conversation.

Alternatively, if you’re keen to learn more about You Build It You Run It, keep an eye out for the next and final piece in this article series.