Yesterday, I bumped into an article that mentions a report published by a supposedly reputed analysis firm (and I wonder what sort of company that is, anyway) in which data from a study is interpreted, implying a conclusion which does not leave “Agile” is a good position.

Unfortunately, it is only available to subscribers, so the information I was able to grasp is second-hand one. If that second-hand information is any accurate in its quotes of the original report I feel more than fine not giving my money to such sort of company; if it isn’t accurate, well, it is law-less Internet anyway…
Even if I touch briefly on the report itself, I ask the reader to take the time to read the summary, its comments and the comment from the leading article; they are enlightening, amusing and infuriating in balanced proportions.

On Generalizing

I consider “Agile” like a tag. A fuzzy, generic tab. Like “Haute Cuisine”, “Prêt-à-Porter” or any other French catchy phrase that one can think of that represents a general style, a product or technique that adheres to some very general principles.
Such tags are surprisingly easy to stick, mind you, and drawing conclusions over such concepts can lead to absurdities such as “Seal fur Prêt-à-Porter does not work too well for eskimos Inuit people” or “Haute Cuisine junk food is a failure, give me a greasy bum anytime”.

Conducting a survey on such an abstract and broad topic, on a very small segment (more than 200 practitioners? How many is more than X, anyway? X + 1? 157000 times X?) and writing a paper trying to draw conclusion and charge for it is shocking.
Most importantly, if the conclusions are of the type “Agile is not for everyone”, “Agile is hard” or “Agile works better only when implemented in smaller projects where the team is highly qualified and third party dependencies are minimal” we are better off interleaving witty conclusions such as “I did Agile for a while and my wife left me” to at least give the reader a laugh.
Or better yet, write a series of articles, substituting the keyword by any other. I volunteer to write “The Waterfall Dilemma”, “The Plumbing Dilemma” or “The Walking-Backwards Dilemma” drawing exactly the same conclusions (keywords aside) after asking random members of my family and cash the check, thank you very much.

What is Agile anyway?

If referred to Software Development, one can refer to the apparently outdated Agile Manifesto and be disappointed by its vagueness (as if Ten Commandments were detailed or complete). Or one can read several books about the maybe dozens of methodologies applying agile principles and good luck coming with a less than twenty paragraph definition.
I will stick with:

A manifesto print-out on the wall plus applying software engineering practices to an iterative delivery process with continuous feedback from the real customer and capable and professional team members inside a high-bandwidth communication network. Take away any of the previous elements are you are asking for trouble”.

• The print-out: well, one can live without it, but it is better is your have it at hand to remind you what we are doing the hard work for
• Software Engineering practices: Instead, let’s write crappy code, without change control, not knowing whether it kind-of-works, switching knobs all over the only environment (production, preferably) you will ever need… And see how that works out for your success, shall we?
• Iterative Delivery Process: or wait until 5 min to deadline to tell the bad news that the production server is not even in the data-center
• Continuous Customer Feedback: or kill the fun to surprise the paying customer with a new color scheme for the application he did not ask you to build
• Capable and Professional Team: or give me any hobo off the streets that can spell C-E-S-A-R. The methodology will provide…
• High-Bandwidth Communication: which version of jQuery? I thought I was writing XAML! Back to the white-board.

Some misconceptions

Agile is glorified Time and Materials

The iterative nature of Agile methodologies makes it hard to shoe-horn fixed price. Tough getting it right; not worthy in my opinion. Does that mean you have free hand to screw your way around and being paid for your mistakes? Well, not really.
Your job as a software developer is develop the software your customer wants, not any other software. That involves interacting with the customer to find out what does he want, challenge him, delivering kick-ass software and show it as soon as possible so that it does not cost the customer an arm and a leg the very useful feature that the test user identified while exploring the software.
Develop unwanted software? Fail. Develop crappy wanted software? Laugh now, cry later. Show something in 6 months? Waste 6 months of customer’s money when he tells you he’d be better off with a desktop application.

Agile is Hard

Not really. Good Agile is hard. Lame Agile is surprisingly easy. Do the same as whatever you where doing before, change no organization or practice because someone complains it is tougher than before and call it something else. Voilà.
And do not forget to blame that expensive coach you brought for a week. Oh wait, he was not that expensive. As a matter of fact he was the cheapest you could find. In reality, he was not a coach, he was someone that your poker buddy met at a strip-club that watched a video on the Internet. It does not matter, though; you paid no attention to anything he said anyway and even if you did, your customer is not going to attend that hippy weekly meeting.

You know what is really, really hard? Professional bakery. The getting up early, tweaking those formulas because the flour served last week is different, investing in modern furnaces, attending courses and listening to the complaints of the customers: why are unsalted baguettes so expensive, if you only have to take the salt away of the normal ones, right?

Agile is a Development Methodology

No, it is not. Is a set of principles that establish a framework in which Software Development is more likely to succeed (in the experience of those who wrote the principles).
Oh, and neither is SCRUM. SCRUM is a project management methodology (and a fuzzy one, I must add). It can be applied to software projects, construction or even parenting. Implement SCRUM and poor practices in any of those areas and you are bound to fail. SCRUM will only make more apparent to everyone earlier in the process of failing.

Agile === No Documentation

That myth might come from the poor wording on the Manifesto: X over Y does not mean “DO NOT do Y”. It should be read as “if you are doing more Y than X, you are more likely to fail. I warned you”.
It happens that documentation is a specially obnoxious task that looses value as fast as isotopes disintegrate. It is like flossing, but taking significantly less effort and having significantly longer durability. And flossing is actually good for you.

Agile == Religion

It is never wrong, there are counter examples that prove otherwise and everything boils down to the people practicing it.
Yup, they are exactly the same. Let’s leave it just right there, pal.

Agile is Developer-Centric

I would say, it is more like developer-fueled. It would be centric if the goal would be software. But, and this may shock many people, it is not, The goal is to satisfy a business need, or a scientific need or… Software is a tool. Everyone hates bad tools. Let tool makers build their tools. Good tools-makers know what they have to do for the tool to perform. And even better tool-makers listen and interact with tool users to improve the quality of the tool.
Remove the tool-user and the maker is out of business. Remove the maker and the user is banging nails with a bottle.

Agile Existence is Mercantilist

This is myth confirmed. Agile exists for the purpose of making money by selling books, services and courses; not for the good it may bring to society as a whole. We will have to wait for a change of government to get paid just for “inventing” concepts. Next rent is paid with a brilliant idea; wait for the laugh of my landlord.
Unfortunately I am forced to say the same about… well, everything out there in Capitalism. Ideas have very little value if they do not bring money home. Of course, no one is forcing you to buy books, services or courses. You may be compelled to invest on them if you think it will help you in your business.
I cannot imagine anyone writing “The Vacuum-Cleaner Dilemma” and concluding that one has to be reluctant of vacuum-cleaners because they are sold my companies willing to make money out of them instead of the work they save to the user. Now, would you buy the same vacuum-cleaner that works very well for your neighbor or would you, in a tight fisting attack, plunge for the purchase of something else that costs one fifth of the price? Think carefully your answer.

Agile is Only for Good People

Well, if you create software you better have damn good software developers, testers, managers and operation guys. Same with doctors, lawyers,…
Give bad tools to good professionals and they are worse off than good professionals with good tools.
Give a monkey a great tool such an smartphone and he’ll be disappointed at how bad it is at opening nuts.
Give a group of monkeys a book on table manners and they will struggle with the fish fork.
Isn’t it fun writing about truisms?

My Personal Take

I care naught about analysis companies. And I care less than that for those that imply that X exists for the sake of money, but fail to see the irony of writing such a statement in a paid paper.

Agile development (by my definition) works for me; apparently works for my company’s clients and I won’t stop investigating and refining ways to do my work better. And I’ll do it for personal pride and for a bigger check. And if and when something better comes in my way I will ditch Agile with no tears and cash more money while weeping loudly.

But please, let that Next-Big-Thing be applied by my extremely talented team of fellow developers, outstanding managers and open-minded clients. I have a feeling we might get lucky that time too.