The Agile "Religion" -- What?

Received

"it seems that software development has caught the agile religion. Personally, I have an issue w/ being unimodal."

What?

First. "agile religion". As in the deprecating statement: Agile is nothing more than a religion? As in Agile is nothing more than a vague religious practice with no tangible value to an organization? Interesting, I guess.

I'm assuming that the author did not read the Manifesto for Agile Software Development. Or--worse-- they read it and find that the four values (Individuals and interactions, Working software, Customer collaboration and Responding to change) are just of no tangible value.

That's alarming. Really. The alternative (processes and tools, comprehensive documentation, contract negotiation, and following a plan without regard to changes) seems like it's a recipe for cost, risk, low-value work and a cancelled project. Indeed, it seems like non-Agile project management is the best way to get to the fabled "Software Crisis" where lots of money gets spent but little of value gets created.

Further, it seems that all modifications of the classic waterfall method (e.g., spiral method as a prime example) specifically create "iterative, incremental" approaches to software development. That is, everything that's not a strict (brain-dead) waterfall has some elements of Agile.

This causes me to think that Agile isn't a religion. It causes me to think that Waterfall methods were a religious practice of no tangible value. All the methodology experiments over the last 15 years have been ways of introducing flexibility (agility, brains) into a foolishly inflexible methodology definition.

Indeed, it appears that the heavy-weigh waterfallish methods are an attempt to replace thinking with process. And it didn't work. So, we have to go back to the thinking part. Only, we call it Agile now.

Religious Wars.

Second. "agile religion" (again). As in methodology discussions are just religious wars? As in methodology discussions are just quibbling over no-value details? Some folks may get this impression of making a choice between Agile vs. Non-Agile methods. I think that those folks haven't actually had the opportunity to work from a prioritized backlog and build the most valuable part first. I think that someone who things Agile is just a religious war hasn't been allowed to fix a broken project plan based on lessons learned during the first release.

Agility.

Third. "unimodal". As in being exclusively Agile is bad? As in sometimes you need to have a rigid, unyielding process that sticks strictly to the schedule irrespective of changes which may occur? That doesn't seem rational.

Change happens. Forcing the inevitable changes to conform to some farcical schedule made up by people who didn't have all the details seems silly. Making contract negotiation the focal point of response to change seems like a waste of effort. Trying to document everything so completely that all possible changes are already accounted for seems impossible. And replacing change with a process that regulates change seems -- perhaps -- unhinged.

There were some links and some charts and graphs attached. I couldn't get past the two sentences above to see if there was, perhaps, something more to it. All I could do was respond with a request for clarification that didn't involve the trivialization of Agile methods. It doesn't seem sensible to try and remove the human element from software development.

I'll provide whatever follow-up clarification surfaces on this topic.

It's interesting to see if the "agile religion" was misplaced, or if there are folks who think that responding to the messiness of real software development is a bad idea.

We tried the waterfall method. And it didn't work very well. Agile isn't a "religion". It's a simple acknowledgement that reality is messy.

---