I live on Midway Atoll, you insensitive clod! ;-)
(http://en.wikipedia.org/wiki/Territories_of_the_United_State...)
Agile is not something you can follow to the letter, like you said it's a bunch of processes that help you succeed. Which ones to apply, and more importantly, how to apply each process is highly dependent on the circumstances.
The way we got the term Agile is that a bunch of people in the '90s were experimenting with processes that were less insane that the waterfall approach that had come to predominate. DSDM, FDD, Extreme Programming, Scrum, and probably others that I'm forgetting now. All of those people got together and said, "Hey, we all have something in common. What is it?"
The answer to that was the Agile Manifesto: http://agilemanifesto.org/
Agile is to an actual process what a subdivision is to a house. If you say you live in the subdivision but are not in an actual house, then you're just wandering around camping in back yards and parks.
I agree that a given process is a collection of practices, and that one can compose different practices into a process, sort of the same way a talented chef can walk into a farmer's market, see what's on offer, and compose a balanced, nutritious, and tasty menu on the fly.
However, in practice, what "doing Agile" mainly means is what happens when an energetic but unskilled 7-year-old decides to be helpful and make dinner. Maybe you get a dinner composed entirely of candy. Maybe they use the stove and make something that is a mud-pie version of a gourmet meal.
That isn't to say that people can't create a good process out of raw practices. It's just that doing it is an expert-level activity, and it requires an immense amount of dedication, experimentation, and careful thinking. That's not what I see when I ask after shops that are "doing Agile". That phrase seems to be used exclusively by people who don't want to think hard about process, and just want to cargo-cult and half-ass their way through things because they're focused on getting a project out the door and/or pleasing the HiPPOs.
Agile is not a bunch of processes. Agile is a philosphical orientation that guides how you do work, including selection and evaluation of processes in light of current team and mission.
In situations where agile doesn't make sense, do you think 'fake agile' can be a better way of working than 1990s waterfall?
There are actually reasonable techniques for doing Agile internally if you have clients who believe they need a traditional requirements-based contract approach. So those people should just do Extreme Programming.
For people with huge legacy projects, I think they really need to do the cost-benefit analysis. People like Michael Feathers make a persuasive case that you can slowly clean up legacy code, and that's much more economical than just suffering through expensive and risky changes.
But if somebody is deciding not to do Agile for considered cost-benefit reasons, they should just say, "Yeah, Agile doesn't make sense for us. We're going to do waterfall." Or they could choose a mini-waterfall process, or any one of the pre-Agile processes that suits them. (If those people exist, they should read McConnell's Rapid Development, which catalogs the options pretty well.)
If that's what they want, godspeed.
The people who make me crazy are the ones who don't actually have the discipline to use a real Agile process and also lack the guts to say, "Yeah, fuck that Agile stuff." I get that people would like to be all hip and Agile, but sending somebody out for a 2-day "certification" and then changing a few labels is not actually making better anything internally, and it's making my life worse.
I don't want people to be fake anything. Be real, everybody! Especially managers. Because it's only admitting where you're at that's going to let you get somewhere better.
As an aside, I don't know any serious Agile person who thinks that doing 100% anything by the book is a good idea. I think it was Ron Jeffries, one of XP's inventors, who said something like : "By the book XP is a good place to start, but it probably isn't where you'll end up." Agile processes all have an inspect-and-adapt component. E.g., the weekly retrospectives and continuous tinkering of XP.
His interpretation of this seems to be "Wing it, and if questioned just explain that we're reacting to change which is the agile way.".
The thing that really kills me about this is that 90% of the people who are "doing Agile" (which is not a thing that you can do [1]) really believe that they are an Agile shop. And then I will ask as many as 3 questions to find out what they're doing is waterfall, or mini-waterfall, or code-n-fix. In the old days I could say, "Hey, you should try one of the Agile processes." Now they think they are doing that and doing it well (after all, they have certificates!), so what can I even tell them?
Everybody I talk to who was involved in the Agile movement in the 2000-2004 time frame has this experience now. Common reactions are rage, tears, and philosophical resignation. (I favor quiet rage, but I suspect resignation would be healthier.) That there are some shops doing very well is consolation, but the early Agile people were hoping for more.
For the whippersnappers who are curious about now-ancient history, my theory on how we went wrong is here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... A big lesson I learned was that if you don't have a trademark and use it to keep quality high, your popular term will get buzzworded to death.
[1] Agile is an umbrella for actual processes, like Extreme Programming. There is no process called Agile to do. Saying you are "doing Agile" is like somebody saying their house is in America, but not in DC or any of the states, just America. If you point out that it's the United States of America and they have to be somewhere; they just shrug.