A [[Method|methodology]] designed to be just-enough rather than complete - it addresses the highest-cost gaps in current practice and is expected to evolve as more is learned. The term comes from Alistair Cockburn's work on agile methodologies in the early 2000s (Crystal, Extreme Programming). Cockburn's argument: a methodology costs more to operate the more practices it contains, and most teams adopt heavier methodologies than their actual situation requires. The lightest methodology that still meets the goal is the one most likely to survive contact with a real team. Three properties distinguish a lightweight methodology from a pilot or a starter: - **Operational, not provisional.** Once chosen, it is the method in use - not a placeholder while a "real" method is decided. Teams operate on it from day one. - **Expected to evolve.** New clusters, new failure modes, and new tooling surface practices that get added; obsolete ones get dropped. The methodology's shape is a function of what the organisation currently knows about its own work, not a fixed schema. - **Discovered, not prescribed.** A team designing one starts from its own pains and brokers, not from a methodology catalogue. The catalogue is consulted only after the local requirements are written. The third property is what separates a lightweight methodology from "adopt method X but only do some of it". The latter borrows a known method and uses less of it; the former builds method from local need, and may end up borrowing fragments from several. A lightweight methodology can grow into something heavier as its scope expands; the heavier version begins life as the lightweight one, not as a separate decision.