What agile was reacting against

Agile is easier to understand as a response than as a method.

The thing it was reacting against: a long specification written in advance, signed off, built over many months, and delivered to people who by then wanted something different. The specification was accurate when it was written and the world had moved. Changes were expensive because the whole structure assumed the plan was right, so change control existed mainly to discourage change.

The alternative is to build a small piece, show it to people, learn, and adjust. Not because planning is bad, but because the most reliable way to find out what somebody actually needs is to show them something and watch their reaction.

The four values, in plain terms. People and how they work together matter more than the process document. Working software matters more than documents describing software. Working with the customer matters more than defending the contract against them. And responding to change matters more than following a plan that has been overtaken.

Note the phrasing: the things on the right have value. Agile does not mean no documentation, no plan and no contract, which is how it is frequently misread by people who found the misreading convenient.

Where it fits. Work with genuine uncertainty about what is needed. Where it fits less well: work with a fixed regulatory specification, or a physical build where you cannot iterate on a bridge.

Most organisations that say they are agile have adopted the meetings and none of the values, which is the worst of both.