For those that have the agile religion, it is routine to express to others why they are not "agile" because they're not doing precisely 72.799 hour iterations, or because they have code coverage of less than 83.002% or other arbitrary measures. That is counter productive. Instead we should be encouraging good behaviour as a general practice, not enforcing it through religion and the humiliation of non-conformists that most religions - including agile - engender. Sensible software engineers do the things that make projects successful and we should maintain that, but without the dogma.

A lively debate is underway among the folks at ThoughtWorks. Starting with Dr. Jim Webber, noted author and ThoughtWorks' top SOA consultant, complaining of religiosity among unnamed colleagues. Does the rise of "Agile religion" signal that the moment has arrived to retire the "Agile" label?The discussion began when Dr. Webber described himself as an Agile atheist

Fellow ThoughtWorker Jeff Santini called Jim out in the comments, disputing the existence of an "Agile religion":

I hear alot of talk about the Agile Religion, but I have yet to hear from anyone who actually subscribes to it. ...



You said you are not Agile because you don't believe in it's religion and you don't accept its dogma. Yet I AM Agile and I also don't believe in its religion nor do I accept its dogma. As a matter of fact I don't have any idea what its religion or dogma are.



In light of the above statement either we have different understandings of what it means to be Agile, or there is something besides these two issues that determines Agility.



But seriously, the Agile Manifesto mentions some pretty good guidelines in my opinion to keep teams focused on delivering software rather than adhering to a (potentially dogmatic) methodology.

To which Jim responded:

I don't think I can call myself agile because others who are agile would find my practices different. For example, I subscribe to (enough) architecture and design; I am also wary of YAGNI as a way to shelve important design decisions under the belief they can be magically retrofitted later. I also like quiet focussed areas in whcih to work, and I'm sure there are other ways I'm sure that I disagree with the orthodoxy.



I don't mean to convey any disrepect for agile practices. As I said in my blog post I like (most of) the engineering and planning practices that agile teams use. But I don't fully subscribe to ADD working environments or full time pairing etc. That is why I am an agile atheist.

Jeff Patton, another top ThoughtWorks' consultant and reknown product designer, shortly thereafter authored there Is No Spoon, why the best software design and development process is all in your head. Using the spoon bending scene from the Matrix as a backdrop, he presented a compelling argument that the highest performing teams do not follow a consistent process. Much of the blog entry is drawn from suspicions confirmed at a UserInterface11 conference presentation by Christine Perfetti. :

The UIE folks expected to find that the highest performing design teams had the best processes; but in fact they found that high performing design teams might not follow a consistent process at all. What they did have was a big toolbox full of techniques and tricks, and a history of adaptation and improvisation. She went on to say that in organizations that had a documented methodology, they could almost predict poor performance.



Colleagues say that Patton is a big fan of Shu Ha Ri, a concept drawn from the martial art of Aikido, whose three levels of learning progressing to mastery roughly translate as:



Shu: traditional wisdom - learning fundamentals, techniques, heuristics, proverbs



Ha: breaking with tradition - finding exceptions to traditional wisdom, reflecting on their truth, finding new ways, techniques, and proverbs



Ri: transcendence - there are no techniques or proverbs, all moves are natural

For those that believe that Shu Ha Ri applies to the discipline of software development, rigid adherence to Agile practices is 'Shu', the first and furthest stage from mastery. Patton wrote:



Deep down in my heart, I know that there's really no process. That I'll really have control over my process when I let it bend and sway like a blade of grass. When I focus on the objectives of my software I try to transcend the process.

