Wednesday, July 16, 2008

10 reasons why Agile is a Load Of Bollocks™

Lets be clear about this: Agile has its good sides, that said...

1. It is essentially undefined- the Agile Manifesto comprises four cryptic bullet points, yet is generally sold as a way to solve gigantically complex software engineering challenges. Compare with for example Prince2 or ITIL, which, at least make a good-faith effort to be comprehensive (although reading a manual for either will be so soul-crushingly boring that it will rob you of your will to live). Advocates of Agile have a propencity to "fill in the blanks", which I fear may offend our friends the Blanks, who are more used to being small holes of indefinition rather than vast tracts of nothingsness stretching off to the horizons in either direction.

2. There has been no scientific or academic verification that Agile methods actually work, mostly because nobody can agree on what exactly Agile methods are.

3. Big ConsultancyTM sells Agile. This means that they have a vested interest in being able to bill hours to customers for Agile, which in turn means that it is best if Agile cannot be understood by customers. Is it vapourware?

4. There is a significant industry that exists to "teach you Agile" through expensive seminars yet independent, peer-reviewed literature on the subject is non-existant.

5. The "not for profit" Agile Aliance seems remarkably profit-driven.

6. Where are all the Open Source supporters? Should they not be the bastions of Agility? The Agile Alliance seems to attract traditional corporate members that are the antithesis of Agility.

7. Agile colonises other methodologies. If a way of developing software is clearly effective, Agile tends to claim it as its own. Scrum, Extreme Programming and Test Driven Development are all well defined and reasonably good approaches in their own right, but are they really subdivisions of Agile?

8. Most experienced software engineers know the best way to make software. It is natural to eventually realize that you have to talk to your customers regularly, that you have to set clear tasks, that planning too far ahead will generally not work. Ditto: unit testing, knowledge sharing and short release cycles. Experienced engineering teams will do all of these things no matter which methodology they adhere to.

9. Although undefined most of its proponents would agree that Agile is about operating with short planning and release cycles. This is not appropriate for every type of project- think: banking system, spaceshuttle control, anything to do with complex mathematical formulae. Great for web-apps though...

10. Yes, we all know that the "waterfall" software development method is broken, indeed the man who originally proposed it, Winston W. Royce, did so in order to illustrate a methodology which could not succeed. The Waterfall is the classic straw man, which is why Agile is usually compared to it rather that other methods.

11. (bonus) What is the difference between "method" and "methodology"- is it the same as difference between "science" and "scientology"?

No comments: