Not Everything Can Be Agile

Abstract

Many enterprises adopting Agile broadly apply it to every kind of work, only to discover — too late — that some Products and Services can never be delivered the Agile way. The mistake is not a preference for Agile over Waterfall; it is the belief that delivery methodology is a property of the enterprise rather than of the work. This article names the pattern, explains why the broad application fails, and points to the Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology for the structured method to make the right choice.

Author: Frank Guerino

The Pattern

It has become routine for enterprises adopting Agile to apply it broadly — to every initiative, every Product, every Service, regardless of what the work actually is. The decision feels like progress. It looks like consistency. It satisfies the very reasonable instinct that the enterprise should standardize how it delivers. And it is, in a great many cases, exactly the wrong thing to do.

The cost is usually discovered too late. A program ships to a date it could never have met. A safety-critical component reaches users with defects it should never have carried. A merger or acquisition spirals because the work was never iterable in the first place. The post-mortem points at execution, at people, at tooling. It rarely points at the methodology choice itself — because the methodology was not really chosen for the work. It was inherited, organization-wide, before the work was looked at.

Why It Fails

The reason the broad application of Agile fails is structural, not cultural. Delivery methodology is not a property of the enterprise. It is a property of the work. The right methodology for a given Product or Service is determined by the intrinsic nature of that Product or Service — by whether the work can be broken into small units, whether those units can be delivered as individually valuable increments, whether those increments can be delivered in consistent cycles, and by how severe the consequences would be if a delivered increment failed in use. No amount of organizational commitment to Agile changes those properties. They are facts about the work.

What makes the mistake persistent is that it does not feel like a mistake. Standardizing on one methodology looks like discipline. It simplifies training, simplifies reporting, simplifies the project management office’s own work. The decision is rarely careless; it is usually deliberate, and defended on reasonable-sounding grounds. That is precisely why the mismatch goes unnoticed: it is not recognized as a methodology error at all, but mistaken for sound, consistent management.

Some Work Will Not Bend

A handful of examples make the point quickly. An aircraft cannot be delivered incrementally. It decomposes into thousands of parts, but the parts have no standalone value to the customer — you cannot ship the wings this sprint and the fuselage next. The aircraft provides value only when assembled.

An integrated circuit cannot be delivered the Agile way either. A chip turn — going back, fixing an error, retesting, and manufacturing a corrected version — is enormously costly and time consuming, and the entire discipline of pre-fabrication verification exists so that errors are found before the chip is fabricated. Production is the most expensive possible place for the work to fail.

The software that controls a six-armed robotic surgical system is more extreme still. Such software cannot fail during surgery, because the cost of failure is measured in human life. There is no opportunity to discover the problem in production and correct it in the next iteration. Failure must be driven out of production entirely, through exhaustive verification before the system is ever used in a live procedure.

A merger, an acquisition, or a divestiture is the same story in a different form. These are bounded, integrated efforts. They do not yield value in independent increments. They are delivered as a coordinated whole, advancing through stages, with verification at each stage before the work proceeds. They are not Agile, they were never going to be Agile, and an enterprise that tries to force them into Agile delivery loses time, money, and credibility.

The Honest Answer

The honest answer is not to abandon Agile. Agile is the precise fit for work that meets its preconditions — work whose units are small, individually valuable, deliverable in consistent cycles, and tolerable in their consequence of failure if a delivered increment fails. That work is extremely common in modern software, and Agile delivers it well. The mistake is not preferring Agile. The mistake is treating it as the methodology, when it is in fact one of three legitimate outcomes.

The right approach is to apply Agile where the work permits it, apply Waterfall where the work demands it, and recognize that real Products and Services are frequently a deliberate combination of both — a Hybrid in which most of the work is delivered as a continuous Agile stream while one or more bounded, integrated components break out and are delivered through Waterfall. None of this is hard to do well if the choice is made at the right moment: at the onset of the Product or Service’s definition, by examining the work itself rather than by inheriting an enterprise-wide standard.

Where to Go Next

The IF4IT has developed a structured framework for making this decision well. It defines four indicators to evaluate, an explicit decision flow that produces one of three outcomes — Agile, Waterfall, or Hybrid — and the discipline to keep the Hybrid outcome honest rather than letting it become an escape hatch. It is designed to be applied chiefly by recognizing the type of work, with formal analysis reserved for genuinely ambiguous cases.

Read the framework here: Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology.

Published by IF4IT.com — The International Foundation for Information Technology