HyperTeamsWhat 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 is enough — skipping this part leaves nothing else stranded.
What agile aimed at
Agile emerged aimed at waterfall's long feedback loop.
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:
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.
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?
Answer
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.
2. Why doesn't doubling headcount double the speed?
Answer
Because coordination cost grows with it. Communication paths grow quadratically (10 with five people, 45 with ten), and meetings and handovers grow accordingly.
3. Why can a one-week sprint be less efficient?
Answer
Because the coordination ratio rises. The meetings stay the same while the working time halves, so the share of the cycle producing output shrinks.
What changes when the coordinator changes → What hyper-agile changes