During my software development career, I have seen many software development approaches or methodologies used in different organizations. When a new and supposedly better approach is promoted, some people tend to adopt it with an attitude that could sometimes be close to a religious zeal. Software companies have noticed this and they now employ “product evangelists”. As a consequence, new believers are often rejecting completely what has been done previously and adopting a “us against them” attitude, especially when the new approach is still a small movement fighting against an established methodology.
This has been the same for Agile, the latest approach on the block, even if the words of the Manifesto for Agile Software Development (“while there is value in the items on the right, we value the items on the left more.”) try to avoid this “forget the past” situation. Most agile coaches agree also that it is more important to make choices according to the context than to apply a prescriptive checklist, but for some people it is easier to follow blindly a model than to absorb a philosophy. You know the proverb: “Give a man a fish, and he’ll eat for a day. Teach him how to fish and he’ll eat forever”. It is however easier to learn how to work with JUnit than to create efficient unit testing cases. Pure agilists quickly fond their “enemy”: the Waterfall, a dinosaur of software process that should be lead to extinction, buried with fossilized Cobol programs in the mainframic stratum of the history of software development. Those with a little bit more of a software process culture will try to fight RUP or the CMMI, which are to Waterfall what tyrannosaurs are to dinosaurs: a more dangerous and ferocious evolution that kill entire forests to produce piles of project documentation.
The last issue of Methods & Tools contains an interesting article from an organization that mixes CMMI and Scrum. Is this an heretic position for adopters of both approaches? Maybe. Do this article tells us that everybody has to do the same things? No. It is just what the company thought is the best for their software development projects in their own context. Does it seem to be a successful approach for them? Yes. So, this is my eleventh commandment of software development: forget the first ten! If you could summarize software development definitively in a small number of rules, Methods & Tools would not exist. You should read everything you can about every approach with a critical but open mind and choose the good tools for your specific context. Nobody detains THE truth valid for all software development projects. We all make mistakes, which is good because you can learn from them.
Isn’t this just begging for someone to say that their twelfth commandment is to forget the first eleven???
On a more serious note, I am fully in agreement with the sentiments, however, most of the failings I have seen is when a methodology is only given lip service. Without commitment to the intent, or as you say philosophy, of any given approach then it is destined to fail.