What Is DevOps? A Plain Explanation for Small Teams

DevOps is a way of working in which the people who write software and the people who run it share responsibility for getting changes to users quickly and safely. In practice that means small changes, automated tests and deployments, infrastructure described in code, monitoring that tells the team when users are affected, and a habit of learning from every failure without blame. AWS’s definition of DevOps↗ (opens in a new tab) puts it in one line: “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.” On a small team the developers usually are the operations team already, so DevOps is less a reorganization than a set of habits.

DevOps meaning: where the word came from

The word joins development and operations, two groups that in many companies used to sit apart: one wrote the code and handed it over, the other kept it running and absorbed the consequences. The name spread through a conference series: the devopsdays organizers↗ (opens in a new tab) record that the first devopsdays was held in Ghent, Belgium, in 2009, with Patrick Debois as founder. There is no standards body and no certification that defines it, which is why definitions vary. They agree on the core: shared ownership, automation, and fast feedback from production.

Microsoft’s What is DevOps↗ (opens in a new tab) guide adds a useful frame: DevOps unites people, process and technology across four phases, plan, develop, deliver and operate, and those phases are not tied to one role. A developer cares how the change behaves in production; whoever runs production has a say in how it is built.

The culture: CAMS, then CALMS

The most quoted summary of DevOps culture is an acronym, and its authors are on record. John Willis set out CAMS, for Culture, Automation, Measurement and Sharing, in a July 2010 post, What DevOps Means to Me↗ (opens in a new tab). In a later article on DevOps culture he writes that he and Damon Edwards coined the acronym after the first US devopsdays, in Mountain View in 2010, and that Jez Humble later added an L, for Lean, to make CALMS. What each letter means on a team of five:

• Culture: the person who ships a change also watches it land. Failures are investigated to fix the system, not to find someone to blame.
• Automation: anything done on every change, such as testing, building and deploying, is done by a machine the same way every time.
• Lean: work in small batches, limit how much is in progress, and remove waiting. A change that sits unmerged for a week is inventory.
• Measurement: a few numbers the team actually looks at, about both speed and stability.
• Sharing: the runbook, the postmortem, the dashboard and the list of what is being worked on are visible to everyone who needs them.

Core DevOps practices

Culture is carried by practices. These are the ones that show up in nearly every definition:

• Version control for everything that defines the system: application code, the pipeline, infrastructure, configuration.
• Continuous integration: every change is merged often and tested automatically.
• Continuous delivery: every change that passes can be deployed by the same automated path, and usually is.
• Infrastructure as code: servers, networks and permissions are described in files and reviewed like code.
• Monitoring and logging: the team finds out about user-facing problems before users report them.
• Small batches: the smaller the change, the easier it is to review, test, deploy and undo.
• Blameless postmortems: every significant incident produces tracked actions, not a culprit.
• Security built in: checks run in the pipeline and secrets never live in the code.

The last item has a US government reference point. NIST’s Secure Software Development Framework↗ (opens in a new tab), SP 800-218, published in February 2022, is a set of secure development practices meant to be added to whatever life cycle model a team already uses, DevOps included. A draft revision, SSDF version 1.2, was released for comment on December 17, 2025; as of September 30, 2026, it has not been published as final, so version 1.1 is still the current one. AWS notes that when security is the focus of everyone on a DevOps team, this is sometimes called DevSecOps.

The tools behind each practice, and which to skip early, are in DevOps tools: the small-team stack. How the practices sit inside the wider path from idea to retirement is covered in software development life cycle.

What DevOps is not

• A tool you buy. A CI/CD service with no tests in it is automation of nothing.
• A job title only. A “DevOps engineer” who alone owns deploys can recreate the old wall between building and running.
• Skipping review to go faster. Speed comes from small changes and automation, not from removing checks.
• Only for large companies. The practices scale down; a team of two benefits from a tested deploy path as much as a team of two hundred.

How DevOps is measured: DORA metrics

The best-known measures come from DORA, a research program run by Google Cloud. It currently uses five software delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Together they show speed and stability, and DORA’s research finds that the two go together rather than trading off. DORA metrics gives the exact definitions and a way to track them with a spreadsheet.

A small-team DevOps checklist

1. Main branch protected: changes arrive by pull request with a passing check and a review.
2. One automated deploy path, and nobody deploys any other way.
3. Tests run on every pull request and block the merge when they fail.
4. Infrastructure and configuration in the repository, changed by pull request.
5. Secrets in a secret store, with an expiry where the system allows one.
6. Alerts on user-facing symptoms, each with a runbook and a person on call.
7. A postmortem after every significant incident, with each action item tracked to done.
8. A monthly look at the delivery numbers, used to pick one thing to improve.

Where AI coding agents fit

AI coding agents write code, open pull requests and run as steps in pipelines. DORA’s 2025 report↗ (opens in a new tab), State of AI-assisted Software Development, sums up its finding as AI being “an amplifier, magnifying an organization’s existing strengths and weaknesses.” For a small team that means the DevOps basics decide whether agents help: DORA’s capability catalog tags version control and working in small batches among the capabilities that matter with AI, because agents raise the volume of change.

• Keep agent changes small and on short-lived branches, with a person at the merge. Reviewing AI-generated code covers what to look for.
• Let the pipeline, not the agent, decide what passes. An agent’s pull request goes through the same tests and approvals as anyone’s.
• Give each agent its own named credential with only the scopes it needs, and an expiry. How to give an AI agent access to your project board walks through it.
• Record what agents did in the same places people’s work is recorded, so a postmortem can tell the two apart.

The sharing part, on a board

The S in CALMS is the part a task board can help with. On fenbs, people and AI assistants are members of the same board, each holding a role, and History records every change with who made it, so an assistant’s work reads as “Claude via” the person it works for. Team rules, such as how a deploy must be approved, go on the Decisions and rules page, decided by a person; every connected AI assistant reads the rules first, and AI context notes hold the facts it should know about your systems. fenbs does not deploy, monitor or page anyone, and it has no sprints, due dates or GitHub integration. It keeps the shared list of work, with its history.