Methodology X and Goats

I've worked in a CMMi certified workplace, where they spend more time preparing for CMMi certification than doing the actual work. And when they do get to do the actual work it'll have more defects than the intended set of problems it was meant to solve. And to fix those defects, you fill in more fields in defect management software than the lines of code required to do the fix. And once it is fixed, it had to be code reviewed by people who knew more about code reviews than coding. Long story short, It's hard to work like this unless you want to make a career out of CMMi.

After this, I worked in an XP development workplace. Most of the stuff made sense for effective teamwork and delivery. There were no documents, code reviews, audits and NO defects. And most of all, the people who used the software were happy, just like the developers who worked on the codebase.

I've always had the perception that Agile was just "common sense" and it eliminates the Waste called Management (Yes, you heard it right Deming, Drucker et al) in software development. I came across a post from a friend validating my perception with an interesting story (http://vinodkumaar.wordpress.com/2011/06/12/agility/):

A hunter watches a mountain goat grazing on the pastures on the side of a highway. A speeding truck loses control and starts veering towards the grazing goat, in split seconds it jumps off to a safe place. The hunter’s kid who was watching all this asked his dad, “Did the goat escape because it is agile?”. The hunter replied “It is just common sense to avoid a speeding truck”.

The goat metaphor was interesting and i'm going to take it too far to make fun of different methodologies:






A CMMi goat will prepare a process document spreadsheet on how it plans to jump.







A six sigma goat will prove that only 3.4 out of one million goats die in that situation.





A scrum goat will go to a weekend scrum certification workshop and become a scrum master before it jumps.






An XP goat prefers to jump in pairs and always tests before jumping.








An agile goat just jumps.

But, if agile is just common sense, why are there so many ways of doing agile? Common sense isn't so common after all and not everybody has an equal measure of common sense.

A methodology/process is just a guideline for solving a problem and not a solution. Just use it as a guideline with lots of common sense. To paraphrase, Rich Hickey's thoughts on Methodologies from his talk Hammock driven development:

If you practice Methodology X, you get good at Methodology X. If you practice problem solving, you get good at the general idea of solving problems... We as software engineers, are in the business of solving problems.

P.S:
Why didn't you make fun of RUP, Lean, Kanban or Methodology Y?
I just ran out of jokes. Please leave your methodology jokes in the comments section below to be added.