Agile has become a set of ceremonies and job titles. The founding document was a page of principles, most of which are absent from what is now practised in its name.
What it actually said
Four value statements, each preferring one thing over another while acknowledging value in both.
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
Which is a reaction to a particular way of building software that specified everything in advance and resisted change.
The context it responded to
Long projects with requirements fixed at the start, delivering after months or years.
Which failed consistently because requirements were wrong, discovered late, and expensive to change by the time anyone found out.
The alternative proposed was short cycles delivering working software, with direction adjusted based on what was learned.
The irony
Individuals and interactions over processes and tools became a set of prescribed processes and a market for tools.
Which is the most commented-upon outcome and is genuinely what happened.
Certification schemes, prescribed roles, mandated ceremonies and consulting frameworks all arrived, and several of the original signatories have publicly criticised what the movement became.
What frequently goes wrong
Ceremonies performed without their purpose. Daily standups that are status reports to a manager rather than coordination between a team.
Retrospectives that identify the same problems repeatedly without anything changing, which teaches the team that raising problems is pointless.
Estimation that becomes commitment, converting a planning tool into a deadline and destroying the honesty that made it useful.
Velocity used as a productivity measure across teams, which incentivises inflating estimates and makes the number meaningless.
The scaling problem
Methods designed for small co-located teams applied across large organisations.
Which has produced frameworks adding coordination layers, and the criticism is that these reintroduce exactly the structure the original was reacting against.
The defence is that large organisations genuinely need coordination and that pretending otherwise is not a solution.
Both positions have substance, and the frameworks' results in practice have been mixed enough that the argument continues.
What holds up
Short feedback cycles, which is the core insight and is well supported.
Working software as the measure of progress, rather than documents describing intended software.
Involving the people who will use the thing throughout rather than at the start and end.
And adjusting based on what is learned, which requires that learning actually changes decisions.
Outside software
The principles have been applied to marketing, operations and other functions with varying success.
Which works where the work involves uncertainty that is resolved by doing, and works poorly where the work is predictable and the overhead of iteration adds nothing.
Applying it universally is the same error as applying the previous method universally.
The practical position
The principles are free and worth reading in the original, which takes two minutes.
Adopting practices without understanding what problem each solves produces ritual, and ritual without purpose is worse than the process it replaced.
Estimation
A persistent source of difficulty and one where the research is reasonably clear.
Software estimates are systematically optimistic, consistently, across decades of study.
Relative estimation — comparing items to each other rather than estimating absolute duration — was adopted to address this and works better than absolute estimation while remaining imprecise.
Empirical forecasting from historical throughput, rather than from estimates at all, has gained ground and generally outperforms estimation for predicting delivery dates.
Technical debt
Shortcuts taken to deliver faster that increase the cost of future change.
Which accumulates invisibly and eventually dominates, slowing delivery until it is addressed.
Short cycles without attention to internal quality accelerate this, which is the most common failure mode of rapid delivery and is why sustainable pace appears in the original principles.
The customer
The principle of close collaboration assumes a customer available to collaborate.
Which is frequently absent in practice, with a proxy inside the organisation standing in.
That substitution removes the feedback the method depends on, and it is the most consequential deviation from the original approach.
Documentation
The principle preferred working software over comprehensive documentation, which was read by many as meaning no documentation.
Which is a misreading — the original explicitly stated value in both.
The practical consequence has been organisations that cannot explain how their own systems work, which becomes acute when the people who built them leave.
Documentation sufficient for someone else to maintain the work is a reasonable interpretation and is considerably less than what the method was reacting against.
Contracts
Fixed-price contracts specifying deliverables conflict directly with responding to change.
Which is why iterative approaches sit awkwardly with procurement processes designed around fixed scope, and it is a genuine obstacle rather than a cultural one.
Time and materials arrangements, or fixed budget with variable scope, resolve it and require trust that procurement processes are designed to avoid needing.