# What agile solved and what still blocks

> **What you will learn**
> What agile solved and where it stalls today. What the number "two weeks"
> really is.

> **This part is for whoever leads the team that builds.** If you are driving
> adoption, [the roadmap](/guide/ax-roadmap-overview) is enough — skipping this
> part leaves nothing else stranded.

## What agile aimed at

Agile emerged aimed at waterfall's **long feedback loop.**

```mermaid
graph TD
  A["Fix all requirements"] --> B["Months of development"]
  B --> C["Show customers when finished"]
  C --> D{"What if the market changed meanwhile?"}
  D -->|"it did"| E["The whole thing is wrong"]
```

The problem was **finding out months later that you were wrong.** The two-week
sprint was a device for cutting that cycle to two weeks — "let's find out within
two weeks."

It genuinely worked. It still does.

## But where does "two weeks" come from?

This is the key question. Why two weeks specifically? Not one week, not a day.

> **It is how long it takes for people to gather, decide, build, and gather
> again.**

In other words, **a number sized to human speed.** Not to the speed of the
development itself.

## What is inside those two weeks

Open up one sprint and it looks like this:

```mermaid
graph TD
  S["Sprint starts"] --> P["Planning meeting"]
  P --> W["Actual work"]
  W --> R["Waiting for review"]
  R --> W
  R --> D["Demo · retrospective"]
  D --> S
  W -.->|"only this segment produces output"| O["The feature"]
```

Only the **"actual work" segment** produces output. The rest is all coordination.

| Item | Character |
|---|---|
| Planning, standups, retrospectives | coordination meetings |
| Waiting for review | the gap between opening a PR and someone looking |
| Context switching | the re-entry cost of moving between tasks |
| Handover and documentation | the cost of moving information between people |

**Coordination cost frequently exceeds the actual working time of one feature.**

## Can't you just add people?

No. Because coordination cost **grows with them.**

```
2 people = 1 communication path
5 people = 10 paths
10 people = 45 paths
```

Paths grow quadratically with headcount, and meeting time and handovers grow
with them. So **doubling the people does not double the speed.**

## So where is the bottleneck?

In summary:

| | Agile solved | What remains |
|---|---|---|
| Feedback cycle | months → 2 weeks | it will not shrink below 2 weeks |
| Course correction | now possible | but on a 2-week cycle |
| Bottleneck | fixing requirements | **human coordination** |

**Agile's bottleneck was not created by agile.** It comes from how people
collaborate, and agile did the best it could inside that.

Which leaves this question:

> **What if the thing doing the coordinating were not a person?**

## Common misconceptions

### "Are you saying agile was wrong?"

No. Agile was **the right answer under the conditions of its time**, and most of
those conditions still hold. Short cycles, fast feedback, and embracing change
carry over into hyper-agile unchanged.

What changes is **the lower bound of the cycle.** With human coordination two
weeks is the floor; remove that coordination and the floor lands somewhere else.

### "We already do one-week sprints."

Shortening the cycle **raises the coordination ratio.** Cut to one week and the
meetings stay the same while the working time halves. Below a certain point you
cannot shorten further.

That is why "just do it faster" is not the answer.

---

## Check yourself

**1. What is the number "two weeks" sized to?**

<details>
<summary>Answer</summary>

**How long it takes people to gather, decide, build, and gather again.** It is
sized to human collaboration speed, not to the speed of development itself.
</details>

**2. Why doesn't doubling headcount double the speed?**

<details>
<summary>Answer</summary>

**Because coordination cost grows with it.** Communication paths grow
quadratically (10 with five people, 45 with ten), and meetings and handovers
grow accordingly.
</details>

**3. Why can a one-week sprint be less efficient?**

<details>
<summary>Answer</summary>

**Because the coordination ratio rises.** The meetings stay the same while the
working time halves, so the share of the cycle producing output shrinks.
</details>

---

What changes when the coordinator changes →
[What hyper-agile changes](/guide/ha-what-changes)