No Agile Gospel please, just give me Enlightenment

For lack of a logo, here's the Snowbird resort where the Agile Manifesto was developed back in 2001

Agile Software Development presently is suffering from evangelisation, it seems. Which is awkward, as it's been around for almost 10 years, and evangelists usually are needed in an earlier phase in life. By now I'd expect Agile temples and churches to self-attract masses of believers. In stead, it's a bit like fundamentalist Christians repeating the 2,000 year old words from the Bible - and I thought that good wine needs no bush?

As there seems to be a Manifesto for everything these days, here's 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.

Glancing over that, I get a rebellious, anarchistic feeling - but that's maybe me. After a lot of reading and discussions with friends and foes, I'm fairly convinced that Agile is a good way to deliver working software in small, close-knit teams. The problem is that it's also being adopted for larger software development projects, even in combination with offshoring - a situation that is clearly not advantageous to Agile

Some of the principles behind the Agile Manifesto are:

• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Even late changes in requirements are welcomed
• Close, daily cooperation between business people and developers
• Face-to-face conversation is the best form of communication (co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances

Again, I see an old-fashioned situation where we're all stuck in traffic on our way to the customer on a daily basis, don't outsource or offshore (part of) the work, and where large vendors or system integrators fit in because they provide the most experience and stability. And yet Agile's only deemed fit for small projects (10-20 people). And there are more who say so

But, my main question is: what if you're driving an Agile car and it breaks down?

It's all fair and square that Agile works because it focuses on software development and delivery, not the entire Application Lifecycle of which typically 20-30% is spent in development, and the remainder in maintenance. There's always a trade-off, and only God can create matter out of thin air

• I understand that it's costly enough as it is to start coding almost right away and change that on an ad-hoc basis if the customer requires so
• I understand that it's too costly to having to change documentation at the same pace of having to change code
• I understand that a great dependency on humans is created if an application's functionality and structure is not described well enough. This is not unique for Agile, but Agile does seem to pay even less (if any) attention to it
• I understand that this dependence on humans will put great strain on regular or irregular test and maintenance in terms of finance and time
• I don't understand why at go-live there isn't an effort made to mature the software delivery by making it "stick" to paper. Not that I deem documentation sacred, and I've been inside more than enough companies to see that it is usually at least incomplete or not full up to date, but:

what if your Agile car breaks down in the middle of nowhere?
Do you ship it back to the factory?

It is so very 20th century to must depend on certain people for anything; I call that the worst form of lock-in, viz. knowledge lock-in. To have to rely on a specific party or company is slightly less worse, and called third-party lock-in. The least of all evils is vendor lock-in.
And yet, you can take your broken-down car and move that to the nearest garage, and chances are they can fix it quickly and against a competitive price. That's because, and only because, they ship each car with ample documentation legible to anyone. Not because they had so much fun and anarchy creating a product that only they themselves could fix or maintain. Heck you could even do it yourself if you had some tools and patience. That's not lock-in, that's Freedom. And it is Freedom that we should give our customers, because they pay well for it

Stop evangelising Agile. Give me Agile TCO. What are the trade-off costs for the increased time and money you have to put into Agile test, and what are the trade-off costs for the increased time and money you have to put into Agile maintenance?
And stop measuring success by projects if you're really all about Software Development. Projects take up 20-30% or even less of an application's lifecycle, so that's only a small portion of the cost. Moreover, it's not until after the release of a product that it is actually going to function for the customer