Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology on International Foundation for Information Technology (IF4IT)

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

Mon, 01 Jan 0001 00:00:00 +0000

About This Document

This document presents a framework for answering a single, recurring question: when an enterprise sets out to deliver a Product or Service, should the work be delivered using an Agile delivery methodology, a Waterfall delivery methodology, or a Hybrid of the two? It is a decision aid. A practitioner applies the framework to a Product or Service and the framework yields a recommended delivery methodology, together with the reasoning behind that recommendation.

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

Mon, 01 Jan 0001 00:00:00 +0000

The following terms are used throughout this document with specific meanings.

Term	Definition
Agile	A delivery methodology in which work is delivered as a continuous stream of small, independent, individually valuable units — commonly expressed as User Stories grouped into Enablers and Epics — delivered in consistent, committed cycles. Agile tolerates the possibility of a delivered increment failing in use, because the consequence of such failure is low and the correction loop is fast.
Waterfall	A delivery methodology in which work is delivered as a bounded, integrated effort that advances through a sequence of stages, with formal verification at each stage before the work proceeds. Waterfall concentrates the detection of failure into pre-delivery stages so that failure is found and corrected before the Product or Service is released.
Hybrid	An outcome in which a Product or Service is delivered predominantly through an Agile stream, while one or more bounded, integrated components are isolated and delivered through Waterfall, reintegrating with the Agile work at defined points. A Hybrid must be earned by demonstrating that the Waterfall components can be cleanly isolated; it is not a default or a compromise of convenience.
Product or Service	A defined thing with an identity and a lifespan, expected to receive intentional improvements over that lifespan. The Product or Service is the entity to which this framework is applied. The term Service is understood broadly: it covers ongoing operational services and also bounded undertakings performed to deliver a defined outcome. Examples include a software application, an integrated circuit, an aircraft, a delivered business service such as claims processing, and a merger, acquisition, or divestiture.
Delivery Methodology	The disciplined approach by which work to create or improve a Product or Service is organized and delivered. This framework concerns three: Agile, Waterfall, and Hybrid.
Unit of Work	A discrete portion of the work required to create or improve a Product or Service. The framework assesses whether work can be partitioned into small units and whether those units can be delivered as valuable increments.
Increment	A unit of work once delivered. An increment is incrementally valuable when it provides standalone value upon delivery, independent of the units delivered before or after it.
Decomposability	The degree to which a body of work can be partitioned into small units. The first structural indicator of the framework.
Incremental Deliverability	The degree to which the small units of a body of work can be delivered progressively, each delivered increment having standalone value. The second structural indicator. Distinct from Decomposability: work may be decomposable yet not incrementally deliverable.
Time of Delivery	Whether the increments of a body of work can be delivered in consistent, committed cycles. The third structural indicator. The test is the ability to commit to a consistent cycle, not the absolute duration of the cycle.
Delivery Cycle	A consistent, committed period within which an increment is delivered. Most commonly one to four weeks in length, though the specific duration is defined by the Product or Service Owner. The defining property of a delivery cycle is consistency and commitment, not its length.
Consequence of Failure	The severity of harm that results if a delivered increment fails in use. The framework’s gating indicator. Severe consequence — harm to humans, material brand damage, regulatory or legal breach, irreversible loss — directs work to Waterfall regardless of the structural indicators.
Fail Fast	The principle of detecting and correcting failure as early and as cheaply as possible. Both Agile and Waterfall pursue this principle; they differ in where, relative to delivery, they locate the point at which failure is detected.
Decision Gate	A point in the framework at which one indicator can determine the outcome on its own, overriding the others. Consequence of Failure is the framework’s decision gate.
Uniformity Check	The step at which a practitioner determines whether a Product or Service is uniform in character or contains work of a materially different character. Applied to work that has been assessed as Agile-shaped, to determine whether a Hybrid outcome should be considered.
Exception Scan	The step at which a practitioner identifies the minority of units within a non-uniform Product or Service that differ in character from the whole. The Exception Scan does not enumerate and classify every unit; it identifies only the recognized exceptions.
Isolability Test	The test that determines whether the exception units identified by an Exception Scan can be separated from the main body of work — behind clean interfaces, on separable workstreams, with defined integration points — so that they run their own delivery cadence without forcing that cadence onto the rest of the work. A Hybrid requires the Isolability Test to pass.
Delivery Cost	The cost to deliver a Product or Service according to its methodology fit. Delivery cost is a property of the work; the tolerance for that cost is a property of the enterprise. Cost is an advisory consideration applied after the methodology fit has been determined; it never rewrites the fit.

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

Mon, 01 Jan 0001 00:00:00 +0000

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.

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

Mon, 01 Jan 0001 00:00:00 +0000

The framework produces one of three outcomes. They are introduced here so that the reader understands the destinations before studying the route.

The first outcome is Agile. Work suited to Agile delivery exists as a continuous stream of small, independent units — commonly expressed as User Stories tied to Enablers and Epics — each individually valuable, delivered in consistent, committed cycles. There is no project. The Product or Service simply continues to be improved, one delivered increment after another, for as long as the enterprise chooses to invest in it. A web portal application and an extract-transform-load process are characteristic examples of work that is naturally Agile-shaped.

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

Mon, 01 Jan 0001 00:00:00 +0000

A widespread misconception holds that Agile fails fast and Waterfall does not. This is wrong, and understanding why it is wrong is essential to understanding the framework. Both Agile and Waterfall pursue the principle of failing fast — of detecting and correcting failure as early and as cheaply as possible. They differ not in whether they fail fast, but in where, relative to the delivery of the Product or Service, they locate the point at which failure is detected.

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

Mon, 01 Jan 0001 00:00:00 +0000

This framework recommends and informs; it does not govern the structural choices that belong to the enterprise. The framework’s posture on when the methodology decision is made follows from that principle.

Most commonly, the delivery methodology is determined once, at the onset of a Product or Service’s definition, and it holds for that Product or Service’s entire lifespan. The methodology is determined at definition because the four indicators are dominated by the intrinsic nature of the Product or Service, and that nature is largely fixed when the enterprise decides what the Product or Service is. Whether a web portal’s work is decomposable, incrementally deliverable, deliverable in consistent cycles, and low in consequence of failure is a property of what a web portal fundamentally is. The same is true, in the opposite direction, of an integrated circuit. The character is set at definition, and the improvements that follow inherit it.

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

Mon, 01 Jan 0001 00:00:00 +0000

Several of the framework’s indicators are expressed using relative terms — work is partitioned into small units, increments are delivered in consistent cycles, a failure causes severe harm. The words small, consistent, and severe have no universal, absolute value. They must be calibrated. The framework does not supply universal thresholds for them; instead, it assigns the responsibility for calibration explicitly to the enterprise, and it identifies who within the enterprise is responsible for each.

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

Mon, 01 Jan 0001 00:00:00 +0000

The framework evaluates a Product or Service against four indicators and produces one of three outcomes. In evaluating a Product or Service, the framework examines the body of work required to create and improve it; the phrases the body of work and the Product or Service are used accordingly, the first referring to the work of delivering the second. The four indicators are not co-equal. One of them — Consequence of Failure — acts as a gate: it is evaluated first, and a severe consequence of failure determines the outcome on its own, regardless of the other three indicators. The remaining three indicators — Decomposability, Incremental Deliverability, and Time of Delivery — form a structural chain, evaluated only for work that passes the gate. They are ordered deliberately, because each depends on the one before it, and a body of work must satisfy all three to be considered Agile-shaped.

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

Mon, 01 Jan 0001 00:00:00 +0000

The first indicator the framework evaluates is the Consequence of Failure. It asks a single question: if a delivered increment of this work fails in use, how severe is the resulting harm? Severe harm includes harm to humans, material damage to the enterprise’s brand, a breach of regulatory or legal obligation, and irreversible loss. If the harm from a failure in use would be severe, the consequence of failure is high. If a failure in use would be tolerable — recoverable, inexpensive, and free of lasting damage — the consequence of failure is low.

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

Mon, 01 Jan 0001 00:00:00 +0000

For a Product or Service whose consequence of failure is low, the framework proceeds to the structural chain, and the first link in that chain is Decomposability. Decomposability asks whether the body of work can be partitioned into small units at all. It is a question about the structure of the work: does the work admit being broken down, or is it an indivisible whole?

Decomposability is assessed against the body of work as a whole, not by examining individual units one at a time. The presence of small units inside a body of work proves nothing on its own — a Waterfall-shaped effort also contains many small units. The question is whether the work, taken in its entirety, can be reduced to small units, allowing for a reasonable number of unavoidable exceptions. Work that resists being made entirely of small units — work that contains irreducibly large, indivisible elements beyond what counts as reasonable exception — fails the Decomposability indicator.

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

Mon, 01 Jan 0001 00:00:00 +0000

The second link in the structural chain is Incremental Deliverability. It asks whether the small units of the work can be delivered progressively, each delivered increment having standalone value. It presupposes Decomposability — there is no point asking whether units can be delivered incrementally if the work cannot be partitioned into units at all — but it is a genuinely separate question, and the distinction between the two is important.

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

Mon, 01 Jan 0001 00:00:00 +0000

The third and final link in the structural chain is Time of Delivery. It asks whether the individually valuable increments of the work can be delivered in consistent, committed cycles. It presupposes Incremental Deliverability — there is no point asking how often increments can be delivered if there are no valuable increments to deliver — but, like the other links, it is a genuinely separate question.

The test of Time of Delivery is the ability to commit to a consistent delivery cycle. It is not a test of absolute speed. As described in the Conceptual Foundations, a delivery cycle is most commonly one to four weeks in length, but the length is a reference point, not a rule. What matters is that the team can commit to delivering increments in a consistent, repeatable cycle. A team that can reliably deliver an increment every four weeks satisfies the Time of Delivery indicator just as fully as a team that delivers every two weeks; the consistency and the commitment are what the indicator measures.

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

Mon, 01 Jan 0001 00:00:00 +0000

The framework combines the gate and the structural chain into a single decision flow. The flow is presented below as an ordered sequence of steps. Each step poses one question; the answer either directs the work to a final outcome or advances the evaluation to the next step. The flow is read from the top down, beginning with the gate and ending, for work that reaches it, with the determination of a Hybrid.

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

Mon, 01 Jan 0001 00:00:00 +0000

The decision flow is presented as an ordered sequence of questions, but it is important to understand how the framework is applied in practice. In the great majority of cases, a practitioner does not formally walk a Product or Service through each step. The practitioner recognizes the type of work and reaches a sound conclusion directly.

The nature of most work is evident on inspection. An experienced practitioner looking at a web portal application or an extract-transform-load process recognizes immediately that the work decomposes, that it delivers in valuable increments, that those increments can be delivered in consistent cycles, and that the consequence of failure is low — and therefore that the work is Agile-shaped. The same practitioner looking at an integrated circuit, an aircraft, a robotic surgical system, or a merger or acquisition recognizes immediately that the work is composed of large, interdependent units, that it cannot be delivered in valuable increments, and that its consequence of failure is high — and therefore that the work is Waterfall-shaped. The decision flow describes the reasoning, but recognition delivers the answer.

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

Mon, 01 Jan 0001 00:00:00 +0000

The Hybrid outcome arises when a Product or Service that has been found Agile-shaped — having passed the gate and all three structural indicators — turns out not to be uniform in character. A Hybrid Product or Service is delivered predominantly as an Agile stream, while one or more bounded, integrated components that are Waterfall-shaped are isolated and delivered through their own staged effort, reintegrating with the Agile work at defined points. In a Hybrid, a team working predominantly in Agile must, for one or more complex components, break out and away from the Agile stream to deliver those components through Waterfall.

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

Mon, 01 Jan 0001 00:00:00 +0000

The four indicators, the decision flow, and the Hybrid evaluation together determine the methodology fit of a Product or Service. That fit — Agile, Waterfall, or Hybrid — is a property of the work itself. Cost plays no part in determining it. Once the fit has been determined, however, a separate and advisory consideration is applied: cost.

Cost enters the framework as a distinct feasibility consideration, not as a fifth indicator. The reason is that cost, unlike the four indicators, is not purely a property of the work. The cost to deliver a Product or Service according to its methodology fit is largely intrinsic to the work. But whether that cost is acceptable depends on the enterprise — on its size, its budget, and its tolerance for expenditure. The same Product or Service, delivered at the same cost, may be readily affordable for a large enterprise and prohibitive for a small one. Delivery cost is a property of the work; cost tolerance is a property of the enterprise. Because the second is organizational rather than intrinsic to the work, cost cannot be one of the indicators that determine the methodology fit.

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

Mon, 01 Jan 0001 00:00:00 +0000

Applying the framework to a Product or Service follows a straightforward sequence. The steps below describe the full procedure; in practice, as noted in the part on recognition, an experienced practitioner will often move through the early steps by recognition rather than by formal analysis.

Identify the Product or Service. Establish the defined thing, with its identity and lifespan, to which the framework is being applied. Confirm that the assessment is being made at the onset of the Product or Service’s definition, or that the enterprise has deliberately chosen to reassess an existing Product or Service.

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

Mon, 01 Jan 0001 00:00:00 +0000

The following brief illustrations show the framework reaching its three outcomes by recognition of the type of work. They are deliberately short. They are not detailed case studies; they are examples of how a practitioner recognizes the nature of a Product or Service and reaches a sound conclusion.

A web portal application is a characteristic Agile outcome. Its consequence of failure is typically low — a defective feature is a recoverable, inexpensive problem. Its work decomposes readily into small units. Those units are incrementally deliverable: a single new feature provides standalone value on delivery. And those increments can be delivered in consistent, committed cycles. The portal passes the gate and all three structural indicators, and if its work is uniform in character, the outcome is Agile. The portal is not delivered as a project; it is improved continuously, as a stream of delivered increments, over a lifespan that may extend for decades.

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

Mon, 01 Jan 0001 00:00:00 +0000

The following pitfalls are the most common ways enterprises misapply, or fail to apply, the principles in this framework.

Forcing one methodology onto all work. The central mistake the framework exists to prevent. An enterprise adopts a single delivery methodology and imposes it on every Product or Service, treating methodology as a property of the enterprise rather than of the work. Work that cannot accept the imposed methodology fails, is reworked, or consumes investment it never should have required.

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

Mon, 01 Jan 0001 00:00:00 +0000

This framework exists to replace a habit with a discipline. The habit is the selection of a single delivery methodology by organizational preference, followed by the imposition of that methodology on every Product or Service the enterprise delivers. The discipline is the recognition that delivery methodology is a property of the work — that it is determined by the intrinsic nature of the Product or Service, evaluated honestly against the Consequence of Failure and the three structural indicators of Decomposability, Incremental Deliverability, and Time of Delivery.