Eight steps that take a product team from manual, risky releases to small, routine ones, and the metrics that show it is working.
In short
DevOps is a way of working where the team that builds a product also owns how it is tested, released and run. Start small: put everything in version control, automate the build and the most important tests, release in small batches, add monitoring, and track the DORA delivery metrics to see whether releases get faster and safer.
Many product teams already work in sprints but still release once a month, by hand, with a long checklist and a nervous evening. This guide is written by Devies, a Gothenburg-based product and engineering consultancy, for product owners, engineering leads and CTOs who want to change that without a large transformation programme. It explains what DevOps means for a product team, gives a step-by-step starting order and shows how to measure progress.
What is DevOps for a product team?
DevOps is a set of practices and a culture in which the people who build software also take responsibility for delivering and running it, supported by automation. For a product team it means that "done" includes being deployed, observed and supported in production, not only merged.
Three definitions help keep the conversation concrete:
- Continuous integration is the practice of merging small changes into a shared main branch often, with an automated build and tests on every change.
- Continuous delivery is the ability to release any change that passes the pipeline to production safely and quickly, at the moment the business chooses.
- A deployment pipeline is the automated sequence that turns a commit into a tested, deployable release.
It is not a job title, a tool or a separate team that does releases for you. Buying a CI/CD product without changing who owns production rarely changes anything. The goal is a short, reliable path from an idea in the backlog to a change users can see, with fast feedback when something breaks.
Where should a product team start with DevOps?
Start with the step that removes the most pain from your next release, and build the rest in the order below, because each step depends on the one before. Most teams can take the first four steps within a few sprints.
- Map your current release path. Write down every step from a merged change to production, who does it and how long it waits. The longest wait or the most manual step is your first target.
- Put everything in version control. Application code, infrastructure definitions, database migrations and configuration (but not secrets) belong in the repository, so every environment can be rebuilt from it.
- Automate the build and the critical tests. Every change should build and run the tests for the journeys that would hurt most if they broke, such as login, payment or data import. Aim for minutes, not hours.
- Agree a shared definition of done. Include "deployed to a test environment", "monitored" and "documented for support" next to "code reviewed". The team owns the whole path.
- Release in small batches. Ship small changes often instead of large ones rarely. Use feature flags to separate deploying code from turning features on for users.
- Automate deployment to every environment. Use the same pipeline and the same artefact for test, staging and production, so a release is a routine step that anyone on the team can run.
- Add monitoring and alerts that the team reads. Track errors, response times and the business events that matter. Alerts should go to the team that built the feature.
- Hold short reviews after incidents. Focus on what in the system allowed the failure, not on who made the mistake, and turn the findings into backlog items.
Security belongs in the same pipeline once the basics run. Our article on DevSecOps and security checks in every release covers which checks to add and where.
How does DevOps fit with Scrum and agile work?
The two fit together: Scrum organises how the team plans and learns, and DevOps practices make it possible to deliver what was planned to users quickly and safely. Agile development (agil utveckling) without a short delivery path tends to produce finished work that waits weeks to be released.
The Scrum Guide describes Scrum as a lightweight framework for generating value through adaptive solutions to complex problems. As of October 2026, the current edition is the one from November 2020. It requires a Definition of Done, which it describes as a formal description of the state of the Increment when it meets the quality measures required for the product. That is the natural place to anchor delivery practices: if "done" includes automated tests and deployment, every sprint moves the team towards continuous delivery.
Practical links between the two:
- Sprint Review is more useful when stakeholders see the change running in production or a production-like environment, not on a developer's laptop.
- Retrospectives are the place to pick the next delivery bottleneck to remove.
- Backlog refinement should include operational work, such as alerts and pipeline improvements, as first-class items next to features.
The Manifesto for Agile Software Development put "working software" and "responding to change" at the centre in 2001. A short delivery path applies the same idea to the last mile of software development (programvaruutveckling): getting working software to users and learning from how it behaves.
How do you measure whether it is working?
Measure delivery performance with the DORA metrics, which track both speed and stability so that the team cannot improve one by sacrificing the other. As of October 2026, the DORA metrics guide lists five metrics in two groups.
Metric
Group
What it measures
Change lead time
Group
Throughput
What it measures
Time from a change being committed to it running in production
Deployment frequency
Group
Throughput
What it measures
How often the team deploys to production
Failed deployment recovery time
Group
Throughput
What it measures
Time to recover from a deployment that needs immediate intervention
Change fail rate
Group
Instability
What it measures
Share of deployments that need immediate intervention
Deployment rework rate
Group
Instability
What it measures
Share of deployments that are unplanned and caused by a production incident
Use the metrics to compare the team with itself over time, not to rank teams against each other. Collect them automatically from the version control system, the pipeline and the incident log where you can; a monthly look at the trend is enough to start.
Common mistakes when starting
- Buying tools first. A new pipeline product does not shorten lead time if approvals and manual testing stay the same.
- Creating a separate "DevOps team" that takes over releases. This adds a handover instead of removing one.
- Automating a slow, flaky test suite as it is. Fix or remove unreliable tests first, or the pipeline will be ignored.
- Skipping monitoring. Faster releases without visibility only make failures arrive faster.
Keep reading
From our work
Client Case: Lea BankLea Bank rebuilt its digital platform with Strapi, React, GrowthBook, GA4, and BigQuery to improve SEO, A/B testing, and marketing autonomy.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is the first step in DevOps?
The first step is to map how a change currently travels from a developer to production, including every manual task and every wait. That map shows where to start: often automating the build and critical tests, or removing a manual approval. Putting all code, infrastructure definitions and configuration in version control is the foundation that every later step depends on.
Is DevOps the same as CI/CD?
No. CI/CD, continuous integration and continuous delivery, is a set of technical practices that DevOps relies on. DevOps is broader: it includes the team owning its software in production, monitoring, learning from incidents and measuring delivery performance. A team can have a CI/CD pipeline and still work in a siloed way where another group handles releases and operations.
Do we need a DevOps engineer?
Not necessarily. Many product teams succeed by sharing the work among existing developers, sometimes with help from a platform or infrastructure specialist who builds reusable pipelines and environments. What matters is that the team owns delivery and operations of its own product. Hiring one person to "do DevOps" for everyone usually recreates the handover that DevOps aims to remove.
How long does it take to see results?
Teams that start with the biggest bottleneck often see shorter lead times within a few sprints, because removing one manual step or a slow test stage has an immediate effect. Building a full delivery pipeline with monitoring and stable metrics takes longer, typically several months, depending on the size of the codebase and how much legacy release process needs to change.
