The Agile Manifest is a pack of lies

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Early deliver of software sounds good but early software is buggy and lacking in features.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This sounds great, it is however a get-out clause for customers not understanding what they need. No other area of business is expected to change course at the drop of a hat. Abandoning the “plan” regularly introduces more problems than it solves. Plans exist for a reason.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This expectation is incredibly vague. We’d like working software without defining what that means, and we’d like it soon but anytime in the next quarter is acceptable… ?

Business people and developers must work together daily throughout the project.

Business people don’t have the stamina to concentrate on software for as long as it takes the developers to build it. Instead business people drift in and out as their attention waxes and wanes.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Trusting people to “get the job done” assumes they know the job and that it won’t change regularly, which we’ve already established is an expectation of Agile. Frequent changes to the “plan” saps motivation, it doesn’t “get the job done”.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The quickest way to convey information is face-to-face perhaps but it’s a terrible way to capture important decisions, to agree on long term goals and plans, or to deal with anything more complex than an absolutely trivial level of detail.

Working software is the primary measure of progress.

“Working” is so ambiguous here as to be useless. MySpace’s software “works” but I’d hardly call it progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Here we ignore everything we know about individual motiviation, team stamina and the realities of work live. Lets just ignore sickness, holidays, training and taking time to reflect on past successes to optimize for the future.

Continuous attention to technical excellence and good design enhances agility.

Attention to excellence and good design doesn’t enhance agility. I think you’ll find that abandoning good design is what enhances agility.

Simplicity — the art of maximizing the amount of work not done — is essential.

I disagree that “work not done” is the same as simplicity, but I agree that simplicity is a virtue in software design — it’s just takes an awful lot of work to achieve.

The best architectures, requirements, and designs emerge from self-organizing teams.

We know this to be false so we appoint scrum masters and development managers to keep teams on-track.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

No objections to this one.

SUMMARY: Agile is like capitalism. It’s sounds good on paper, it fails to deliver on most of it’s promises most of the time but it’s best we’ve found so far so we’re sticking with it.