How to be an Agilista

Pronunciation
That's Aj-ill-eesta, it comes from the Latin meaning literally "toss pot". It has a similar route to the name of a coffee brewer at Starbucks (Barista - bah-ree-sta - "coffee pot").

Fervour
Agilistas are nothing without fervour. If you cannot be excited about it as though it's a cult, then you should not even dare to call yourself an Agilista. After all, not only is Agile trendy, but it's based on sound engineering principles. Let's forget that the evolution method, waterfall method and countless other approaches are also based on the same sound engineering principles. Let's also forget that there are various other processes out that which produce the same results as Agile with the same (or less) effort, but just in a slightly different way. You have to believe that Agile is the king and you are the serf to it... but also the master of anyone you consider too stupid to understand why your pet approach is the only way forward.

Name dropping
A lot of Agilistaism is about who you mention. If you can mention Kent Beck or Ward Cunningam then you're laughing (probably in a maniacal fashion). If you can mention them and claim to have met them, extra points. If you can do it and claim to have written code with them, then quadruple extra points. If you can say it in an apparently blasé way, but fail to conceal your excitement, then minus two points for you, mudafokker.

It's not just the names of people, Ron Jeffries, but it's also the names of books (ooh... the white book...) which will get you noticed as an Agilista. A lot of this is showing off what you think you know, most of which is common sense... in fact you're demonstrating your commitment to the world of Agile. The more of the right books you read the more time you've invested, probably your own spare time, in giving your soul to the collective.

If Agile is not sounding like a cult, then you're not doing it properly. You have to sound like a cult... member.

Silly metaphors
A knowing smile, a glance at a fellow Agilista and then you can be happy to say things like "Are you a pig or a chicken". It's important to be able to explain these metaphors too, and you must not lose your nerve when you do so, even though they sound stupid. However, the key thing is to have these metaphors by the cart load. For Pigs and Chicken, the official explanation is "Well, if a pig and a chicken set up a business called bacon and eggs, the chicken would be involved, but the pig would be committed". Additionally you can add that the fox can stay with the farmer on the south bank, leaving the chicken in the boat with the corn, provided that the farmer's wife brings the pig with her when she buys the magic beans. It's very simple, really.

Promoting dogma
It doesn't matter whether some of your techniques would work in only 20% of the cases and simply be almost impossible to apply everywhere else. The fact that they've worked is reason enough to promote the dogma. The best example of this is "story writing". If you can stick to the idea that a story can be written for every discrete block of work, despite all evidence to the contrary, then you are indeed wealthy and the world will be yours.

One of the best ways to do this is, when faced with resistance or complaint about the fact that the real world doesn't fit your particular model, to insist that people have a go at attempting to shoehorn their problem into your restricted viewpoint. Then, when they fail, they've already committed to seeing it your way.

Changing your mind without apologising
Being Agile means never having to say you're sorry. The story cards are, again, a good example. Promoted as the only way to provide requirements, they can soon be dropped or made less important and you need only to mention that you've found them less useful and you can continue unabated, as though you didn't push the point with them in the first place.