Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology

The framework is applied to a Product or Service. A Product or Service is a defined thing with an identity and a lifespan, expected to receive intentional improvements over that lifespan. A web portal application is a Product or Service. So is an integrated circuit, an aircraft, a robotic surgical system, and a delivered business service such as claims processing. Each has an identity — it is a recognizable, named thing the enterprise governs — and each has a lifespan over which it is created, improved, and eventually retired.

It is essential that the framework begins with the Product or Service, and not with a project. A project is a bounded effort with a defined beginning and end. To begin the analysis with a project would quietly presuppose that the work comes pre-bundled into a bounded effort — and that presupposition is itself a Waterfall-shaped assumption. Work that is genuinely suited to Agile delivery does not take the form of a project at all. It takes the form of a continuous stream of small, independent units of work, delivered one after another over the lifespan of the Product or Service, with no project boundary around them. In a genuinely Agile setting there is no project; there is an ongoing flow of delivered increments.

For this reason, the framework treats the word project as one of its possible outputs, never as its input. A project is what Waterfall-shaped work produces — a bounded, integrated effort with edges. Agile-shaped work produces a continuous improvement stream, not a project. By starting from the Product or Service — a methodology-neutral entity that may be delivered either as a continuous stream or as a bounded effort — the framework avoids prejudging its own answer. The shape the work turns out to take is a finding of the framework, not an assumption fed into it.

A Product or Service has a lifespan, and over that lifespan it receives intentional improvements. A web portal may be in service for decades, improved continuously the entire time. An integrated circuit or an aircraft likewise persists for decades, advancing through successive versions. The Product or Service is the persistent entity; the improvements are the work. This distinction matters for understanding when, and how often, the methodology question is asked — a subject addressed later in these Conceptual Foundations.

The term Service should be understood broadly. It covers ongoing operational services, such as a claims processing service that the enterprise runs and improves continuously. It also covers bounded undertakings that an enterprise performs to deliver a defined outcome — work that is clearly not a Product and is not an ongoing operational service either. A merger, an acquisition, and a divestiture are characteristic examples: each is a Service in the sense the framework intends, because each is a defined undertaking with an identity, with a lifespan, and with intentional effort directed at delivering an outcome. The framework applies to such undertakings exactly as it applies to a software application or an integrated circuit. This breadth matters because some of the most consequential work an enterprise delivers — a major organizational transformation, a regulatory program, a merger — is outcome-shaped rather than thing-shaped, and the framework is intended to reach all of it. A merger, acquisition, or divestiture is, by the nature of its work, a characteristic Waterfall undertaking, as later parts of this document discuss.