Delivery models: waterfall and agile in context

How software gets from a developer's workstation into production is rarely a neutral technical decision. Companies pick frameworks based on their risk tolerance, business goals, and engineering culture. A team building autopilot software for commercial aircraft will demand stricter controls than a startup racing to validate a new product idea.

Two broad models dominate the conversation. In the waterfall model, a project is divided into sequential phases, each expected to finish before the next begins. It came out of construction and manufacturing, where rework is expensive and requirements tend to be stable. The criticism that flaws can surface late—forcing a return to earlier stages—has produced variants like the Rational Unified Process, which introduces iteration within phases, and Sashimi, which allows phases to overlap partially.

Waterfall still has a place even in modern technology environments. Cloudflare uses it for infrastructure rollouts, where scope is well understood and unlikely to shift mid-execution. It's also suitable for very large projects with complex dependency trees.

Agile is less a single process than a family of related approaches, grounded in the agile manifesto. Most flavors share a common skeleton:

  • Short release cycles that allow regular feedback from real-world usage.
  • A prioritized backlog where teams pull the most valuable items first.
  • Self-organizing teams working at a sustainable pace.
  • A continuous improvement mindset, where processes evolve rather than harden.

Agile branches into iterative methods like Scrum, where teams work toward shippable increments in set timeboxes called sprints, and flow-based methods like Kanban, where work is pulled from the backlog as capacity allows. A team updating existing products may prefer the predictable rhythm of Scrum, while a team responsible for production monitoring and incident response needs the flexibility of Kanban to react to changing priorities.

A framework for many teams, not one process

Cloudflare's engineering organization is made up of dozens of distributed teams, each with its own product from a single service to shared internal platforms. A young product team might want rapid-fire releases to adapt to customer feedback; a platform team may put stability above all else. No single approach fits both.

Instead of enforcing one delivery model, Cloudflare defines high-level concepts and common language, and lets each team pick its own mechanics. The emphasis is on managing what teams build, not dictating how they build it.

The unit of work at the highest level is called a SHIP—a change intended to reach customers. All active SHIPs appear on an internal roadmap known as the "SHIP-board," visible across the company. SHIPs are scoped to be deliverable in a month or two, with a preference for smaller increments delivered more frequently.

A single SHIP may require coordinated delivery from several teams. This is managed by creating an EPIC within the SHIP for each contributing team. There's a rule preventing a SHIP from containing another SHIP, which avoids circular dependencies. Product Managers own SHIPs; Engineering Managers typically own EPICs. EPICs can also exist independently of any SHIP—this is how technical improvement projects, such as performance tweaks or backend fixes, are tracked once teams decide to do them.

Below the EPIC level, Cloudflare imposes no strict delivery model. Teams are free to use whichever frameworks fit their work. In the Product Engineering organization, product and engineering managers meet weekly to review progress across SHIPs and EPICs. The SHIP-board is automated and includes a linter that flags issues before the meeting arrives. Teams are walked through one by one, with the most linted items getting attention first. Visual icons aid quick reads: a monkey marks a target date that moved in the past week, and bananas count how many times a date has slipped.

Quarterly planning with continuous delivery

Planning recurs every quarter, forcing teams to jointly decide what makes it into a SHIP and what gets left out. About four weeks before a quarter ends, product managers begin compiling their proposed SHIPs, collaborating with engineers on the work required and estimating effort. Cross-team dependencies are identified early so the teams owning the dependent work can schedule around them. The kind of dependency matters—full serialization isn't the only option, and in practice parallel work that integrates toward the end is preferred.

Alongside SHIP-linked EPICs, teams reserve capacity for unlinked EPICs—projects that don't directly serve a SHIP but still matter, like tooling improvements or maintenance work.

Delivery happens continuously throughout the quarter. A grace period means anything shipped in the first two weeks of the following quarter still counts as on-time, since network stability is prioritized over hitting arbitrary dates. Similarly, target dates are treated pragmatically. As work progresses and new complexity surfaces, date changes are acceptable as long as the justification is sound. External commitments are held to stricter standards.

Allowing teams to define their own processes doesn't mean no rules. In the past year Cloudflare blocked an average of 87 billion cyber threats per day, and the infrastructure must treat every deployment with care. Simple, hard rules still govern how code reaches data centers: minimum review counts per piece of code, and phasing deployments so changes are exposed to a subset of traffic first, allowing issues to be contained before full rollout.

The balance comes from defining shared interfaces and guardrails rather than micro-managing workflow. An overly restrictive process creates friction and risks pressing engineers too hard. A lighter touch lets each team concentrate on its actual purpose—protecting customer traffic and building reliable software.