DevOps PeachSix common challenges — and what people typically say:
| Challenge | Typical quote |
|---|---|
| Complexity | "Where should I start?" |
| Cultural changes | "We do Waterfall here!" |
| Lack of standardization | Every team has its own pipeline style |
| Lack of expertise & experience | "I have no Ops in my team" |
| Lack of time | "We're on a deadline, later" |
| Security is not job zero | "Security is not my responsibility" |
DevOps maturity — 5 levels:
flowchart LR L1["1 Novice<br/>silos, manual deploys"] --> L2["2 Beginner<br/>partial automation, each team differs"] L2 --> L3["3 Intermediate<br/>shared DevOps team, documented tools"] L3 --> L4["4 Advanced<br/>consistent process, full monitoring"] L4 --> L5["5 Expert<br/>IaC, zero-touch deploy any time"]
Roadmap (with a decision gate between phases): 1. Phase 0 – Assessment: survey the current state (SDLC, tooling, operations, platform, security & compliance), measure a baseline (DORA metrics), set a target vision. 2. Phase 1 – Adoption planning: roadmap, standardized pipeline (toolchain, stages, quality gates, dashboards), governance model. 3. Phase 2 – Execution: a POC on one project, build community and culture, improve continuously, then scale out.
Preparation: align with business goals, get stakeholder buy-in, remove repetitive manual work. Benefits: technical (continuous delivery, fast fixes), cultural (engaged teams), business (faster features, stable environments).
Traps: buying tools before assessing the current state; rolling out company-wide instead of a POC; leaving security out of the pipeline (build it in from the start — DevSecOps).
Releases are usually tagged; counting tags is one way to measure deployment frequency.
| Command | Meaning |
|---|---|
git tag -l 'v*' |
List release tags starting with v |
The CALMS framework
A common way to check whether a transformation covers more than tools:
| Letter | Area | Question to ask |
|---|---|---|
| C | Culture | Do Dev, Ops, QA, and Security share goals and blame-free learning? |
| A | Automation | Are build, test, deploy, and infrastructure repeatable without manual steps? |
| L | Lean | Are work items small, and is waste (waiting, hand-offs) removed? |
| M | Measurement | Do we track DORA metrics and use them to decide? |
| S | Sharing | Are knowledge, tools, and dashboards shared across teams? |
Team structures
- Cross-functional product teams own a service from code to production ("you build it, you run it").
- A platform team builds an internal developer platform (pipelines, templates, clusters, observability) that product teams use self-service, the idea behind platform engineering.
- Site Reliability Engineering (SRE) applies software engineering to operations, with service level objectives and error budgets that balance speed and stability.
A separate "DevOps team" that only runs pipelines for everyone often becomes a new silo, the very thing DevOps tries to remove.
Learning from incidents
Blameless post-mortems look for the system causes of an incident (missing alert, risky manual step) rather than the person who typed the command, and end with concrete actions. Teams that punish mistakes learn to hide them.
Measuring progress
Take the baseline DORA metrics in Phase 0 and compare every few months. Useful extra signals: how long a new developer needs to make a first production change, how many manual steps remain in a release, and how often deployments happen outside working hours. Improvement should show in both speed and stability; speed alone with more incidents is not success.
Start small, show value
Pick a POC project with a willing team and visible pain, automate its pipeline end to end, publish the before-and-after numbers, and let that success pull other teams in.