The Cascades Methodology
Cascades is a structured delivery methodology that replaces ceremony with software-enforced discipline. Four phases, each producing an artifact the next phase consumes. No sprints, no standups, no ceremony; just structured delivery.
Most process frameworks encode discipline in humans: Scrum Masters, RTEs, sprint rituals. Cascades encodes discipline in software. The platform enforces the structure; the human provides direction and judgment. No ceremony tax, no process drift, no dependence on one person holding the methodology in their head.
The cycle has four phases. A failure upstream costs hours to fix; the same failure caught downstream costs weeks. Cascades catches it upstream.
Cascades emerged from practice. The driftless platform was built end to end through this cycle by the agents that run on it, heuristic from day one: discovery, trial and error, structure that proved itself in shipped software. We gave the pattern a name only after it had already shipped a product. That's what agile was supposed to be: working software over ceremony, discovery over doctrine.
Shape
Business conviction becomes structured, testable work. A business analyst agent translates "we need better access controls before go-live" into paired PRDs and tech specs, decomposed into focused sections with bidirectional traceability. Each section gets a task with TDD-ready acceptance criteria (Given/When/Then). Dependencies are mapped. Sequencing is determined by what unlocks the most downstream value, not by what feels easiest.
BA agent shapes; human directs. The human brings conviction ("this is what matters"). The agent brings structure ("here's how it becomes shippable work").
A complete spec: PRD sections (what and why), tech spec sections (how), tasks with testable ACs, and a dependency graph.
The paired spec sections.
Bad specs produce bad code. Bad code produces rework. Rework is the silent killer of every engineering team. Shaping eliminates the waste that comes from bad cross-domain communication, the most common failure mode in software delivery. A BA agent shapes in 40 minutes what used to take a week of cross-functional meetings, and the output is testable, not aspirational.
Gate
Spec gates evaluate every PRD and tech spec section pair across three gates:
- Integrity. Is each spec buildable? Are acceptance criteria testable? Is there traceability between requirements and tasks?
- Collisions. Do sections contradict each other? Are the same patterns being specified three different ways? Does the PRD contain architecture that belongs in the tech spec (cross-contamination)?
- Consequences. Are there dependency gaps? Missing tasks for defined requirements? Unimplemented sections with no owning task?
When a gate fails, work is blocked, not warned. The gate does not suggest; it prevents downstream execution until the spec is clean.
Automated (deterministic checks) and agent reasoning (LLM checks). No human review required for the gate to run.
A clean spec with zero fails, or a blocked spec with specific, actionable findings pointing to the exact section and the exact problem.
A gated, clean spec that is ready to build.
Catching a contradiction at spec time costs minutes of reading. Catching the same contradiction at code time costs weeks of rewriting, plus the rework ripple across dependent tasks. Gates make spec quality a gate, not a hope. They also enforce spec separation (product requirements vs. architecture), which prevents the entangled specs that produce entangled teams.
Ship
Persistent coding agents execute the shaped, gated work. Each agent reads its task directive (full context: description, ACs, project context, linked tasks, comments), writes code, runs tests, and posts progress updates. The work was already defined in Shape and validated in Gate; the agent is executing, not guessing. Multiple agents work in parallel on independent tasks; dependency chains prevent agents from starting blocked work.
Coding agents. Humans monitor, not micromanage.
Code, tests, and progress commentary, all logged for audit.
Shipped code with passing tests and linked evidence.
The shipping phase is where most process frameworks add overhead (standups, sprint reviews, status reports). Cascades replaces status meetings with task commentary, a decision log anyone can read. Agents persist across sessions; they do not lose context between Monday and Thursday. The human's role shifts from managing the process to directing the work.
Verify
Acceptance criteria, written TDD-ready in the Shape phase, are verified against shipped code. Each AC has a clear pass/fail: "API response under 200ms at p95" passes; "the system should be fast" does not exist. CI gates run. Regression tests run. Agent code review runs. A human verifies the final result and marks it done.
The failure is detected automatically; nobody has to watch CI to catch it. The agent reads the failing check, re-plans the work, creates a new attempt, and retries without human intervention. A retry is not a blind repeat: the agent diagnoses why the previous attempt failed and changes its approach before trying again.
Retries are bounded, not endless. Transient failures (rate limits, timeouts, flaky infrastructure) are retried up to three times with exponential backoff before the error surfaces. When the retry budget is exhausted and the work still fails, the agent stops retrying and escalates to a human blocker: it posts a comment documenting each attempt, the outputs it saw, and why each one failed, then sets the task to blocked. The task waits for a person to decide. Nothing auto-closes, and failed work is never marked done.
Automated validation first (CI, tests, code review); human verification last.
Working software, proven. Tasks move to done only after a human confirms. No auto-closing, no status inflation.
Failed verification routes back to Shape (if the spec was wrong) or Ship (if the implementation was wrong). The cycle is a loop, not a line.
"Done" means proven, not declared. The acceptance criteria were locked at spec time, so there is no retroactive negotiation about what "done" means. Verification is deterministic: the same AC that was written in Shape is the one being tested in Verify. No scope creep, no definition-of-done drift.
The cascade effect
The name is not decorative. Each phase cascades into the next:
- Shape produces the spec that Gate evaluates.
- Gate produces a clean spec that Ship can execute without ambiguity.
- Ship produces code that Verify can test against locked criteria.
- Verify feeds back into Shape when specs need correction.
A failure at any phase is contained at that phase. A spec contradiction caught in Gate never reaches Ship. A failing test caught in Verify never reaches done. The cascade is a containment structure; problems do not flow downstream.
Contrast with the dominant pattern: a vague ticket goes to a developer who guesses at requirements, ships code, discovers the spec was wrong in review, and reworks. Cascades makes that pattern structurally impossible.
What's intentionally absent
Cascades removes the process rituals that consume engineering time without improving the software. What is gone, and what replaces it:
- Sprints. Work flows continuously. Sequencing is driven by dependencies, not timeboxes.
- Standups. Task commentary is the status report. It is always current and does not require a meeting.
- Sprint planning. The dependency graph IS the plan. It updates as work completes.
- Ceremony tax. The methodology is enforced by the platform. No human bandwidth is spent maintaining the process.