# Run and Change in One Team: Organising Operations and Development in an Agile Way

Author: Marin Niehues, Niehues Consulting · Published: 2024-08-05 · Delivery & Steering
Source: https://www.niehuesconsulting.de/en/blog/run-and-change-one-team/

Run and change belong in one team when operations absorb less than half of the team's capacity and the team owns a product from development through to operations. Capacity is divided into a fixed share for operations and a share for development, and the work runs in classes with rules of their own. If operations absorb more than half, the operating effort has to be reduced first, before the teams are cut afresh.

This article is written for heads of department and delivery leads whose teams are worn down between incidents, requests and planned development. It compares three organisational forms by criteria, shows a calculation for dividing capacity and describes how operational work can be steered in an agile team.

**A team that owns operations and development together has to fix the capacity for both tasks in advance. Without that, the urgent work displaces the important.**

## Why do teams fail when they own run and change at the same time?

They fail because operational work arrives irregularly and disrupts the planning of development. An incident on Monday morning overturns the sprint the team planned the Friday before. After a few weeks the team delivers reliably neither in operations nor in development, and those involved experience both as overload. The Scrum Guide of 2020 provides no separate place for such work: everything the team does belongs in the Product Backlog, and the Sprint Goal counts as a commitment. Unplannable operational work fits this picture only if the team reserves capacity for it.

There is a further characteristic of the work itself. Operational work is usually urgent and small, development large and effective over the long term. Teams that mix both in one list handle the small and urgent first, and development slips back. The result is the maintenance of a product that no longer improves.

## When do run and change belong in one team?

They belong in one team when the operations share is below half, and the reasons are learning and ownership. Werner Vogels, chief technology officer of Amazon, coined the principle "You build it, you run it" in a 2006 interview in ACM Queue: the team that builds something also operates it. The reason is a feedback loop. Whoever answers for an incident at night or on Monday morning builds the product so that it fails less often. If an organisation separates operations from development, knowledge is lost at the handover, as the article on [handovers between departments](/en/blog/handovers-between-departments/) describes.

Skelton and Pais assign this ownership in "Team Topologies" (2019) to stream-aligned teams, which own a flow of work from idea to operations. The limit lies where operations absorb so much attention that no capacity remains for development. The Google team responsible for running the company's own services published a rule for this in 2016 in the book "Site Reliability Engineering": operational work such as tickets, on-call duty and manual routine may take up at most half of a team's time. The remaining time belongs to improving the system. The rule applies there to operations teams. Carrying it over to teams that develop and run a product is this article's own judgement, and it serves as a yardstick for deciding whether a team can own both. More on cutting teams is in the article on [Team Topologies](/en/blog/team-topologies-organising-teams-for-flow/).

## Which three organisational forms exist?

There are three forms: rotation, capacity reserve and a separate operations team. Which one fits is determined by the share of operations in team capacity, which you measure over the last twelve weeks. The thresholds of 20 and 50 per cent are a rule of thumb of this article, and only the 50 per cent has a precedent in Google's rule. The 20 per cent follows from the arithmetic that one person in a team of six ties up about one sixth of the capacity.

**Three organisational forms for run and change**
Criterion | Rotation | Capacity reserve with classes | Separate operations team
Operations share | Below 20 per cent | 20 to 50 per cent | Above 50 per cent or its own on-call duty
Principle | One person per sprint takes over operations | A fixed share of capacity is reserved for operations | A separate team with its own planning
Strength | Everyone learns the product in operation | Flexible when volumes fluctuate | Clear ownership, specialisation
Weakness | The person is missing from development | Needs honest measurement of the reserve | Handover between teams, loss of knowledge
Precondition | Few, short incidents | One shared list with classes of work | Clear interface and handover criteria

In a rotation one person per sprint takes all incoming operational requests and is released from development. The others work undisturbed on the sprint plan. After the sprint the duty changes hands. This pattern suits teams with few and short incidents.

With a capacity reserve the team plans only the part of its capacity that remains after deducting the measured operations share. Operations and development sit on one shared list, and the work is divided into classes.

A separate operations team pays off when the operations share is above half or when operations require on-call duty that does not sit well with development. The handover between the teams then needs clear criteria so that knowledge is not lost.

## How do you calculate capacity for operations and development?

Capacity follows from three steps: the measured operations share, a buffer for fluctuation and the remaining plannable balance. In the first step you establish from the last twelve weeks how much time the team spent on operational work, from tickets, time bookings or a simple weekly estimate. In the second step you add a buffer of about one fifth of the measured value, because operational work fluctuates. In the third step you plan development only with the balance.

An example to illustrate, with assumed values: a team of six has 30 person-days per week. The measurement shows that on average 9 person-days flow into operations, which is 30 per cent. The buffer of one fifth is around 2 person-days. The team therefore reserves 11 person-days for operations and plans 19 person-days for development. If the operations share falls over several weeks, the reserve is reduced. If it rises, the cause is investigated before the reserve grows. The method complements the considerations in the article on [capacity planning in agile teams](/en/blog/capacity-planning-agile-teams/).

## How do you steer operational work alongside development?

You steer it through classes of work, which David Anderson describes in his book on Kanban of 2010 as "classes of service". Each class has its own rule for priority and deadline. Four classes are enough for run and change: incidents, which are handled at once and interrupt everything else; work with a fixed date; standard work, which runs in sequence; and improvements without a date. The four classes adapt those Anderson describes (expedite, fixed date, standard, intangible) to operations. The incident class receives a ceiling, for example one incident at a time, so that it does not flood the board. How such limits improve flow is explained in the article on [Kanban](/en/blog/introducing-kanban-flow-over-utilisation/).

**Four classes of work**
- Incident: immediate handling, interrupts current work, limited number
- Fixed date: planned so that it is finished before the deadline
- Standard: sequence by priority, cycle time is measured
- Improvement: no deadline, a fixed reserved share of capacity

What matters is that improvement work on operations receives a fixed share. Automating recurring incidents lowers the operations share and creates capacity for development. Teams that drop this work as soon as things get tight remain stuck in operations permanently.

## What is the role of leadership?

Leadership sets the operations share, protects the reserve and decides on the ceiling for incidents. It names one person per product who decides the priority between operations and development, usually the product owner. Without this decision point, team members negotiate each incident individually with the business unit, and the loudest caller wins. Leadership watches two metrics: the operations share over time and the age of the oldest development item on the board.

## Run and change with Niehues Consulting

[Niehues Consulting](/en/) is a consultancy for AI management and organisational design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver and works as delivery manager, project manager and product owner on projects ranging from VC-funded scale-ups to DAX 40 groups. In the service area of delivery management and organisational design, this includes cutting teams and responsibilities for operations and development and clarifying the decision paths for them.

The approach follows the Niehues Delivery Model. Three of its test questions matter here: Who decides, who delivers, who uses? Which roles, decision paths and interfaces does operations need? Who is responsible for operations from day one? The entry point is a free initial consultation of 30 minutes, which you can arrange via [contact](/en/#kontakt). Scope and terms of an engagement are discussed there.

**Conclusion**
Run and change belong in one team as long as operations absorb under half of the capacity. The measured operations share determines the form: rotation below 20 per cent, capacity reserve between 20 and 50 per cent, a separate operations team above that. Classes of work, a ceiling for incidents and a reserved share for improvement keep both tasks moving.

**Sources**
- Gray, Jim; Vogels, Werner: A Conversation with Werner Vogels, ACM Queue, 2006
- Beyer, Jones, Petoff, Murphy: Site Reliability Engineering, O'Reilly, 2016 (ceiling of 50 per cent for operational work)
- Anderson, David J.: Kanban, Blue Hole Press, 2010
- Skelton, Pais: Team Topologies, IT Revolution, 2019
- Schwaber, Sutherland: The Scrum Guide, 2020

## Frequently asked questions

### Can a Scrum team also run operations?

Yes, a Scrum team can take on operations if it reserves capacity for it and makes the operational work visible in the Product Backlog. A rotation or a fixed share of capacity is usual, so that the Sprint Goal remains plannable.

### What does "you build it, you run it" mean?

The principle means that the team that develops a product also operates it. Werner Vogels of Amazon formulated it in 2006. It links ownership with learning, because the team experiences incidents in its own product first-hand.

### How much capacity should a team reserve for operations?

The team should reserve the measured operations share of the last twelve weeks plus a buffer of about one fifth. If the share is above 50 per cent, reducing the operating effort matters more than planning.

### When do you need a separate operations team?

A separate operations team pays off when the operations share stays above half or when on-call duty displaces development. The handover between the teams then needs clear criteria.

### How do you handle incidents during a sprint?

Incidents go through a rotation or a reserved capacity, and the Sprint Goal is agreed only with the plannable balance. A ceiling for simultaneous incidents prevents them from filling the board.

### What are classes of service?

Classes of service are classes of work with their own rules for priority and deadline, described by David Anderson in his Kanban book. Typical classes are incident, fixed date, standard and improvement.

### How do you measure a team's operations share?

You measure it over twelve weeks from tickets or time bookings by setting the time spent on operational work against total capacity. A simple weekly estimate is enough to begin with.

### How do you reduce operating effort?

You reduce it by automating recurring incidents and removing their causes. The team needs a reserved share for improvement work that stays in place even in tight weeks.