In Search Of Best Methodology

There was a time when Agile nazis zealots used to make me feel bad. I’d feel guilty about not following The Agile by the book. We did not do stickies with user stories, had no burn–down chart, did not calculate velocity, etc. We had a similar, less intricate process, and it worked reasonably well for our needs.

Over the past couple of years I realized this: it makes little sense to follow any methodology “by the book.” Oh, there will be people instilling a sense of guilt if you don’t have a love relationship with Rhino Mocks or don’t write unit tests first. They would gladly bite your head off and scream that you’re doing disservice to the community and should therefore apologize.

Tom DeMarco (of Peopleware fame) has a great essay on the subject of processes and management in Why Does Software Cost So Much? (hat tip to Michael Nygard):

The bread-and-butter mechanism by which an organization improves is simple enough: People identify best practices that are already working somewhere within an organization and propagate them. This involves no great breakthrough, no new theory. It is basic hygiene. Companies that can do it survive and prosper, and those that can’t don’t.

Head First Software Development (love their books!) has a similar theme about the illusion of silver-bullet processes:

There’s no single process that magically makes software development succeed. A good software process is one that lets your development team be successful.

In general, I’m a proponent of iterative development; I don’t believe in Big Up-Front Design (BFUD). However, I treat agile methodology only as a good starting point, not the be all and end all.