Flow - why hydro works

This part explains why dependency-driven development works better than time-boxed sprints in the AI era. Understanding these principles helps teams implement hydro effectively and adapt it to their specific context.

Flow is not a thing you track or manage, it's the underlying principle that makes hydro work. Like gravity enables water to find its path, the flow principle enables work to find its natural progression through dependencies rather than artificial time constraints.

Dependency-Driven Flow vs Time-Boxing

The difference between these approaches becomes clear when you see them in practice:

Aspect	Time-Boxing (Traditional)	Dependency Flow (hydro)
Work starts when...	Sprint begins	Dependencies clear
Work completes when...	Sprint ends	Quality gates pass
Progress measured by...	Story points delivered	Capabilities unlocked
Planning focuses on...	"What fits in 2 weeks?"	"What should we build next?"
Bottleneck is...	Dev capacity	Decision making
Optimization target...	Sprint velocity	Flow efficiency

Instead of asking "How much can we squeeze into this sprint?", you ask "What's ready to flow with the wave?"

For detailed dependency management, see Dependencies.

In hydro, waves complete when their work is genuinely done:

• All functionality implemented and tested

• Quality standards met

• Integration verified

• Business value delivered

For wave execution details, see Waves.

Creating Flow Conditions

Flow happens when (hybrid) teams create the right conditions:

Clear dependencies → every task knows what it needs and what it unlocks. No ambiguity about prerequisites or downstream impact.

Blockers removed → decisions happen quickly. Technical blockers get immediate attention. No waiting for the next planning meeting.

Quality gates → work progresses when it meets quality standards, not when the calendar says it should.

Continuous availability → if there is the case, AI can work 24/7. Human reviews happen asynchronously. No bottlenecks from timezone differences or meeting schedules.

You know "you're in the flow" when:

✔︎ Features ship days after conception, not sprints later

✔︎ Developers focus on architecture and decisions, not ceremonies

✔︎ Teams talk about possibilities unlocked, not story points

✔︎ Quality improves because there's no rush to "make the sprint"

Epic Integrity and Business Value

An important principle: epics flow as complete units. When a business capability requires five tasks, all five travel together through the same wave. This ensures:

Splitting epics across time boundaries fragments value delivery. In flow-based development, business capabilities remain intact.

For epic management details, see Epics.

The Result

When teams "flow" with flow principles, the change is dramatic. Instead of fighting against artificial constraints, work progresses naturally from conception to production. Developers spend less time in ceremonies and more time solving problems. Business value ships continuously rather than in prescribed increments.

Remove the dams, and water finds its way. Remove artificial time constraints, and work finds its natural rhythm.