Practical Application of DevOps
What this domain covers
Practical Application tests how DevOps is adopted in a real organization: value stream mapping, team design, culture change, metrics and risk-based change management. Questions ask what to do first, which metric to use, or why a transformation stalled.
Start with the value stream
Map the path from idea to customer. Separate touch time from wait time; in most organizations the majority of lead time is waiting, not working. Improve the constraint rather than every step. Value stream mapping gives a shared, evidence-based starting point.
Teams and culture
Build small, cross-functional teams with end-to-end ownership: you build it, you run it. Platform teams provide self-service capabilities so product teams do not rebuild infrastructure. Psychological safety and blameless postmortems make it safe to surface problems. Leaders set intent and remove obstacles rather than mandating tools.
Metrics
The DORA four key metrics are lead time for changes, deployment frequency, change failure rate and time to restore service. Use them to guide improvement, never to rank individuals or teams. Complement them with flow metrics such as work in progress, throughput and cycle time.
Change management
Replace heavy manual gates with automated evidence and risk-based controls. Smaller, more frequent changes reduce risk. Compliance can be codified as automated checks. The change advisory board is not necessarily abolished, but its role shifts from approving every change to setting policy.
Worked example
An enterprise pilots DevOps on one service. Value stream mapping shows 70% of lead time is waiting for a test environment. The team builds self-service environment provisioning, cutting lead time from 30 days to 5. Reasoning: the pilot identified a system constraint, not a tool gap; scaling then requires a platform team and a product approach to internal services, not a company-wide mandate.
Traps that cost marks
- Launching a big-bang transformation or copying another company's org chart.
- Measuring success by the number of tools or the size of the DevOps team.
- Treating DORA metrics as individual performance targets.
- Leaving security and operations out of the pilot until the end.