The DevOps loop
Delivery is a loop, not a line: what happens in production feeds straight back into what the team plans next.
Continuous feedback
Plan
Work items are prioritized from business goals and from what production and users are telling you.
Core DevOps principles
Continuous integration & continuous deployment
Automate the build, test, and deployment process. Integrate code changes frequently. Deploy to production automatically after passing automated tests. Reduce manual errors and accelerate feedback loops.
Automation everything
Automate repetitive tasks: builds, tests, deployments, infrastructure provisioning, security scans. Free human time for high-value work. Reduce errors from manual processes. Ensure consistency across environments.
Collaboration & culture
Break down silos between teams. Shared responsibility for quality and reliability. Blameless post-mortems. Continuous learning and improvement. Experimentation and innovation encouraged.
Measuring delivery performance
The DORA research program popularized four key metrics that balance speed and stability. I use them to start a conversation and track progress, not to rank teams.
Deployment frequency
How often changes reach production. Small, frequent releases are easier to test, easier to understand and easier to undo.
Lead time for changes
The time from a commit to that commit running in production. Long lead times usually point to manual steps, handovers or queues.
Change failure rate
The share of deployments that cause a problem in production and need a fix, a hotfix or a rollback.
Failed deployment recovery time
How quickly service is back to normal after a failed deployment. DORA renamed this metric from time to restore service in 2023.
Speed and stability are not a trade-off: teams that deploy small changes often tend to have fewer and shorter incidents, because each change is easier to test and to reverse.
Habits I help teams build
Tools make DevOps possible; habits make it stick.
Work in small batches. A change that can be reviewed in minutes can be merged and deployed with far less risk.
Keep the main branch releasable at all times, with short-lived branches and pull requests.
Agree on a definition of done that includes tests, documentation and monitoring, not only working code.
Hold blameless reviews after incidents that look for causes in the system and the process, not in the person.
Make work visible on one board shared by development, operations and the business.
Reserve capacity for improvement work such as flaky tests, slow pipelines and technical debt.