# What hyper-agile changes

> **What you will learn**
> What this methodology actually changes, and the fact that the bottleneck does
> not disappear — it moves.

## It changes one thing

> **It moves coordination from people to AI agents.**

This is not about chopping sprints finer. As
[the previous chapter](/guide/ha-agile-limits) showed, that only raises the
coordination ratio.

## What disappears when agents coordinate

| With people | With agents |
|---|---|
| Planning meetings | none |
| Waiting for review | none (reviewed concurrently) |
| Context-switching cost | none (each has its own context) |
| Handover documents | none (the same workspace) |
| End of day, weekends | none |

Remove these and **the lower bound of the cycle changes.**

```
People coordinating: floor = how often people can gather → 2 weeks
Agents coordinating: floor = how long the work itself takes → minutes to hours
```

## What stays the same

This part matters. The good things about agile carry over.

| Unchanged | Why |
|---|---|
| Short feedback cycles | they get shorter |
| Embracing change | it gets easier |
| Working output first | unchanged |
| Human judgement | **more important** |

That last row is the key one. People are not reduced — **their role moves
earlier.**

## Comparison

| | Agile | Hyper-agile |
|---|---|---|
| Unit of work | a feature | **a single issue** (micro-sprint) |
| Cycle | 1–2 weeks | minutes to hours |
| The developer's output | code | **intent** |
| Bottleneck | human coordination | **clarity of intent** |
| Nature of code | an asset — it accumulates | **a consumable — rebuild it if needed** |
| Definition of done | review passed | **tests passed** |

Each row is the subject of the following chapters.

## The bottleneck does not vanish, it moves

This is the easiest part to misread.

```mermaid
graph TD
  A["Coordination bottleneck removed"] --> B["The next bottleneck surfaces"]
  B --> C["How precisely can you say<br/>what you want built?"]
```

**Put in vague requirements and you get vague output very quickly.** Faster speed
means faster travel in the wrong direction too — it is
[an agent going just as hard in the wrong direction](/guide/ai-agent-basics)
showing up at organisational scale.

So the human job changes:

| | What people do |
|---|---|
| Agile | write code. Review. Coordinate |
| **Hyper-agile** | **define intent. Set the criteria for judging. Approve** |

## Is this right for us — check first

Before adopting the methodology, check one thing.

> **Are your tests dense enough to judge "done"?**

Hyper-agile treats **tests as the sole criterion for done.** If that criterion is
weak, you build the wrong thing quickly.

Adopt this methodology first in an organisation with no testing culture and you
end up **fast but with nobody able to judge quality.** In that case, building the
test discipline comes first.

## Common misconceptions

### "Does this mean developers are unnecessary?"

No. **What they do changes.** Defining intent precisely, setting the criteria for
judgement, and judging the results remain. And those can only be done by
**someone who knows the domain.**

If anything, the value of domain knowledge rises. Only the relative weight of
code-writing skill falls.

### "Isn't this overkill at our size?"

You do not have to adopt the whole methodology — **individual pieces work on
their own.**

- Splitting work into atomic units → useful at any size
- Using tests as the definition of done → any size
- Self-healing loops → requires an automation pipeline

Starting with the first two is fine.

---

## Check yourself

**1. What is the one thing hyper-agile changes?**

<details>
<summary>Answer</summary>

**Who does the coordinating.** It moves from people to AI agents. It is not about
making sprints shorter.
</details>

**2. Where does the next bottleneck appear once coordination is removed?**

<details>
<summary>Answer</summary>

**Clarity of intent.** Vague requirements produce vague output very quickly. So
the human role moves forward, from "writing code" to "defining intent and setting
the criteria for judgement."
</details>

**3. What must you check before adopting it?**

<details>
<summary>Answer</summary>

**Whether tests are dense enough to judge done.** Hyper-agile treats tests as the
sole criterion, so without a testing culture you get speed with nobody able to
judge quality.
</details>

---

Now the three core concepts, one at a time. First, the unit of work →
[Micro-sprints](/guide/ha-micro-sprint)