The OTR Group logoThe OTR Group
← All articles
Project Management

Agile: Four Myths and What the Manifesto Actually Says

Agile is often described as "no planning, no documents". The manifesto itself says something more careful. Here is myth versus fact.

Few project terms are used as loosely as "agile". Depending on who you ask, it means daily stand-ups, sprint boards, or simply "doing things quickly". The original Manifesto for Agile Software Development is shorter and more careful than most people remember. Reading it again is a good way to separate myth from fact.

What the manifesto says

The manifesto lists four value statements:

It then adds the sentence that is so often forgotten: while there is value in the items on the right, the authors value the items on the left more. The right-hand items are not banned. They are simply weighed differently.

Myth 1: Agile means no planning

Fact: The fourth statement prefers responding to change over following a plan, but it does not say plans are worthless. Good agile teams plan frequently and in small steps, adjusting as they learn. A plan becomes a working hypothesis rather than a promise carved in stone.

Myth 2: Agile means no documentation

Fact: The manifesto values working software over comprehensive documentation. The word "comprehensive" matters. The aim is to avoid heavy paperwork nobody reads, not to avoid writing things down. Short, useful documents that help people do their work still have a place.

Myth 3: Agile means no contracts

Fact: Customer collaboration is valued over contract negotiation, but contracts still exist. The point is that working closely with the customer usually delivers a better result than arguing over the wording of a specification. In practice, many teams use contracts that allow scope to evolve.

Myth 4: Agile is only for software

Fact: The manifesto was written about software development, and its language reflects that. Many other teams have borrowed its ideas, such as short feedback loops and close collaboration, and adapted them. Borrowing the thinking is reasonable; just be clear which ideas you are applying and why.

Agile and structured methods

Agile is sometimes presented as the opposite of structured approaches such as PRINCE2. In reality, many organisations combine them, using structured governance at programme level and iterative delivery within teams. The useful question is not "which label do we use?" but "what level of control and flexibility does this project need?"

A quick self-check for your team

  1. Do we talk to our customer or user regularly, not just at the start and end?
  2. Can we change direction without a major argument?
  3. Do we deliver something usable early and often?
  4. Is every document we produce actually used by someone?

If you can answer yes to most of these, you are living the spirit of the manifesto, whatever you call your method.

The takeaway

Agile is a set of values, not a ritual. Read the original statements, keep the sentence about valuing the left over the right, and you will find it easier to use the ideas sensibly and to challenge those who misuse the word.

Source: Manifesto for Agile Software Development, agilemanifesto.org. This article is general information only.