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

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.

• Treating Hybrid as an escape hatch. Declaring a Hybrid whenever a decision feels difficult, rather than confronting the honest answer. A Hybrid must be earned: the Waterfall-shaped components must be genuinely identifiable and must pass the Isolability Test, and the practitioner must be able to name which components break out and where they reintegrate. A non-uniform Product or Service whose Waterfall components cannot be isolated is a Waterfall Product or Service, not a Hybrid.

• Letting cost rewrite the fit. Allowing the cost of delivering work according to its true methodology fit to silently change the recorded fit. Cost is advisory and is applied after the fit is determined. Where cost forces a departure, the departure is recorded as a deliberate compromise alongside the true fit — never in place of it. An enterprise that cannot see its compromises cannot manage them.

• Confusing decomposability with incremental deliverability. Assuming that because a body of work can be broken into small units, it can therefore be delivered in valuable increments. The aircraft is decomposable into thousands of units yet cannot be delivered incrementally, because its units have no standalone value until assembled. Agile delivery depends on incremental deliverability, not on decomposability alone.

• Mistaking the everyday meaning of risk. Treating the framework’s gating indicator as a measure of how uncertain or how difficult the work is. The gate measures the Consequence of Failure — the severity of harm if a delivered increment fails in use — not the uncertainty of the requirements or the difficulty of the work.

• Never revisiting a decision when needs have genuinely changed. Treating the methodology decision as permanent under all circumstances. Most commonly the methodology is determined once at definition and inherited thereafter, and routine improvements are never reassessed. But the enterprise is always free to reassess when its needs genuinely change, and it should not mistake the common pattern for an absolute rule.

• Mistaking a ground-up rebuild for a routine improvement. Forcing a severe re-platforming or a ground-up rebuild through the methodology the Product or Service has used for its routine improvements, simply because that methodology was inherited. Work whose intrinsic nature differs substantially from the existing Product or Service may require a different methodology, and the enterprise is free to assess it accordingly — whether or not the enterprise chooses to treat that work as a new Product or Service.