The "Z" Word

Zealot: A fanatically committed person.

Hmmm... good or bad?

It suggests an unfavorable hue to me. I've seen this word used before to describe folks' commitment to a particular technology platform. He's a .NET zealot, or a Ruby zealot, or Zope zealot.

In the case of technology (most cases?) zealots prefer their approach/solution to all(?) others. For instance, how could you turn back from having written significant code in Ruby to doing plain old Java? Those who aren't writing in Ruby have simply not yet been shown "the way".

I consider myself fairly pragmatic and reasoned, but I seem to have acquired the dreaded tag at work. My zealotry is in an agile approach to software development. (English zealots - note the use of the article "an" vs. the article "the" - it's an important distinction).

I'm measuring whether I should shrug the label off, welcome it with open arms, or fight it. Actually ... that's not quite accurate. I'm pretty sure shrugging it off will not be my chosen response.

At some level, I feel it's like being called a "rationality" zealot... or a "damned common sense practitioner". I'm a "Sunrise Zealot" damn it ! I find the agile manifesto chock full of common sense. (OK, here I see... manifesto => zealotry... maybe if Kaczynski and Marx hadn't also used the term manifesto we'd be in better shape).

Some software development professionals unabashedly promote a "waterfall" approach using a document-centric "SDLC" lifecycle. Templates are created to capture every known aspect of the project. Stakeholders are forced to "sign off" on documents, which form a contract-like agreement to what will be delivered. Of course, a change request process is included, which affords the opportunity to create change documents which are then signed-off.

Agile is not binary... agile is a continuum. There are agile development techniques and agile project management approaches. You can use any of them - or not. The use of one technique does not an agile project make.

Agile, chunked up, (to me anyway) is about focusing on the delivery of quality software over and above delivering service to a process. The customer is not a color-copier and a list of signatories to a spec. The customer is the user of the software; the organization that benefits from working, functional, valuable software. No organization prefers reams of documents over working software. And those that argue voluminous documentation better leads to working, functional, valuable software should start measuring the extent to which those documents are implemented as stated. After all, not many approaches refine their processes to eliminate waste (ala Lean).

One should question the value of accepted process (using the Five Whys, for example) in order to assess the usefulness of documents and other artifacts to ensure they stand the test of reason.

OK, my writing therapy is done. I hereby embrace the label "Agile Zealot". I also accept the following additional labels: "Fatherhood Fanatic", "Beer Lover", and "Education Enthusiast".

I do like the alliteration angle though... may I please be an "Agile Aficionado" instead? Ah, but perhaps that doesn't quite capture the intensity of my rapture.