This article is based on insights originally discussed in a GigaOM webinar on “DevOps Beyond the Controlled Environment,” featuring Nigel Kersten of Puppet. The five steps below are a distillation of what has worked for a number of organisations — they are not a rigid methodology, but a practical guide.
The Challenge of Scaling DevOps
You’ve run a successful DevOps pilot. Your controlled initiative delivered faster deployments, tighter feedback loops, and measurable improvements. Now the business wants more — not just in one team or one product line, but across the enterprise.
This is where most organisations hit a wall. Scaling DevOps means working within real constraints: legacy toolchains, entrenched processes, siloed teams, and organisational cultures that weren’t built for continuous delivery. You rarely get the luxury of starting from scratch. Instead, you have to build on the foundation you already have — however crumbling it may be.
The five steps below offer a structured way to think about that journey. They build on each other deliberately, and the sequence matters.
Step 1: Start by Mapping the Value Stream
Before you automate anything or standardise a single toolchain, you need to understand where value is actually being created — and where it is being destroyed by waste, delays, or rework.
Value Stream Mapping (VSM) is a technique borrowed from lean manufacturing. Applied to software delivery, it gives you a visual representation of every step in the process from idea to production — including the wait times, handoffs, and bottlenecks that slow everything down.
VSM answers a critical question that pure speed-focused approaches often ignore: Are we deploying the right things? By tying every activity back to the value it delivers, VSM ensures that when you do speed up your pipeline, you are accelerating outcomes that matter — not just shipping faster for its own sake.
Practically, this means walking the entire delivery process end-to-end with the people who actually do the work. Map each step, measure the lead time between steps, and identify where work sits idle. The resulting map becomes the shared baseline for every subsequent improvement.
Step 2: Apply Just Enough Standardisation
Once you understand where value flows — and where it stalls — you can begin making things move faster. Standardisation is the highest-leverage lever available at this stage, because it reduces variation without requiring heroic effort from individual teams.
The key principle here is bottom-up standardisation. Start at the lowest level of the stack where you can reach the most people:
- Infrastructure layer: Agree on VM configurations and OS versions that cover the vast majority of workloads. Lock these down as approved baselines.
- Middleware and libraries: Once the OS layer is stable, standardise the runtime environments and shared libraries that teams build on top of.
- CI/CD tooling: Finally, converge on common continuous integration and deployment pipelines. This is the layer most teams want to standardise first — resist that urge until the layers below it are stable.
The discipline here is not to over-standardise. You want just enough consistency to reduce unnecessary variation and make automation feasible. Mandating a single way of doing everything will cause resistance and slow adoption. The goal is a shared platform, not a monoculture.
Step 3: Work Towards Continuous Deployment Through Automation
Automation is the engine of DevOps at scale, but it only delivers its full value when steps 1 and 2 are in place. Automating a poorly understood process just makes you fail faster. Automating inconsistent environments creates a different mess for every team.
With a mapped value stream and a standardised stack, automation becomes genuinely transformative. It removes the manual, repetitive work that consumes engineering time — provisioning, configuration management, testing, deployment — freeing teams to focus on higher-value problem-solving.
The path to continuous deployment is incremental:
- Automate infrastructure provisioning (configuration management, infrastructure-as-code).
- Automate build and test pipelines (continuous integration).
- Automate deployment to non-production environments.
- Introduce automated deployment gates and progressive delivery (canary releases, feature flags) on the path to full continuous deployment.
Prioritise automation that affects the most people and removes the biggest bottlenecks identified in your value stream map. Small wins compound quickly.
Step 4: Set Realistic and Manageable Goals
Scaling DevOps across an enterprise is a multi-year effort. One of the most common failure modes is attempting to transform everything at once — and succeeding at nothing.
The Pareto principle applies directly here: focus on the 20% of changes that will deliver 80% of the improvement. In practice, this means:
- Identify the teams, products, or pipelines where DevOps practices will have the greatest impact.
- Expand DevOps adoption incrementally, using each success as evidence and a template for the next adoption.
- Resist the temptation to mandate adoption across the business before you have proven the approach at meaningful scale.
Crucially, as Nigel Kersten highlighted in the original webinar discussion: authority and responsibility must match. The people accountable for delivering DevOps outcomes must also have the remit — budget, headcount, and organisational authority — to actually make the changes required. Without this alignment, even well-designed programmes stall.
This also means adapting the goal to what is viable in each context. An approach that works for a greenfield microservices team may need significant modification before it applies to a team maintaining a fifteen-year-old monolith. Calibrate expectations accordingly.
Step 5: Aim for Organisational Change, Not Just Process Change
Process improvements and toolchain upgrades are necessary, but they are not sufficient. The organisations that successfully scale DevOps are those that achieve a genuine shift in how people think about software delivery — not just how they execute it.
Agile and DevOps principles are often well understood inside development teams, but poorly understood — or actively resisted — by the operations, compliance, finance, and business units that software delivery teams depend on. Expanding DevOps at scale means bringing those parts of the organisation along, not treating them as obstacles.
The mechanism for achieving this is a series of small, visible wins. Each successful DevOps initiative should be:
- Measured — did it achieve the intended outcome?
- Communicated — are the results visible to stakeholders who were sceptical?
- Reflected upon — did the people involved come away convinced that this is a better way of working?
That last point — the shift in individual conviction — is what drives genuine cultural change. When a team that was initially resistant to DevOps practices has a direct positive experience, they become advocates. That advocacy is more powerful than any top-down mandate.
The long-term goal is to move from an organisation that delivers products and services through linear, project-based thinking to one built on continuous learning, continuous improvement, and continuous delivery of value.
A Cross-Cutting Concern: Feedback and Information Sharing
Running through all five steps is a single requirement: feedback loops and shared information. Each step should be treated as a collaborative activity, not a task handed down from a central DevOps team.
Consider value stream mapping as an example. Conducting VSM within a single team generates useful local insight. Conducting it with a cross-departmental group — including operations, security, and business stakeholders — generates shared understanding and shared ownership of the problems it surfaces. That shared ownership is what makes the subsequent steps stick.
The scope of this collaboration will be constrained by organisational realities: who is willing to act as executive sponsor, how well certain business units already work together, and what is politically feasible. Work within those constraints initially, while actively extending them over time.
The overall goal is pragmatic: deliver DevOps as broadly as is genuinely feasible today, knowing that each success builds the credibility and capability to go further tomorrow.
Summary: The Five Steps
- Map the value stream — understand where value flows and where waste accumulates before changing anything.
- Apply just enough standardisation — bottom-up, from infrastructure to CI/CD, to reduce variation and enable automation.
- Automate towards continuous deployment — incrementally, prioritising changes that help the most people.
- Set realistic, manageable goals — expand DevOps adoption incrementally, ensuring authority matches responsibility.
- Drive organisational change, not just process change — use small wins to shift mindsets and build a culture of continuous improvement.