Here is the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This manifesto is quite reasonable. However, people – well, corporations – keep misapplying it. Let’s talk about that.

Individuals and interactions over processes and tools

You should have a defined process for anything that you intend to repeat. If you can reify those processes in software tools, that means you can automate away the boring bits and ensure consistency. That’s great. Definitely do that.

If, however, you need an exception to be made, the process and any tools implementing it must be bypassable. That’s the nature of exceptions. They happen, they should be documented, and if they happen often, it’s time to look at re-working the process and then the tools.

And if the nature of your work is that a pre-agreed process is really important, for whatever reason – then Agile isn’t what you need.

Working software over comprehensive documentation

Obviously, it’s better to have a product you can hand the client than to have a pretty manual to go along with it. And a lot of products can be used with quite minimal documentation.

And just as obviously, if documentation is a necessary and vital component of your product, Agile is not what you need.

Customer collaboration over contract negotiation

There are actually two parts to this. The first is that your customer needs to have somebody designated who can make decisions and say yes. In the trivial case where the customer is a singular person, hey, no problems here. But if you have a single customer which is a medium or large company – or even a small company with a diversity of needs – it’s actually quite rare to have a single representative of the customer who can say. (And common to have many representatives who can each say no.)

The second part is that contract negotiation needs to be flexible, to protect both sides. The customer doesn’t want to be exposed to the risk of unlimited costs or unlimited delivery time; the developer doesn’t want to be constrained to produce software with poorly defined acceptance criteria or lifetime free scope creep.

Do I need to point out that if your product is strongly regulated by contract – say, something in the medical industry – Agile is not for you?

Responding to change over following a plan

It should now be obvious to you that there are businesses (or organizations) for whom Agile is a great fit, and others where it really isn’t appropriate at all. And it should also be obvious to you that lots of companies are Doing Agile officially, even though not a single one of the manifesto bullets applies to their situations. I am not saying that Agile is superior, or inferior, to any other methodology. I am very much stating that Agile is not appropriate for some projects, and forcing it to fit will make no one happy.