To Agile or not to Agile?

"Prejudices are what fools use for reason." - Voltaire

I've never much liked Voltaire's philosophy, but he has a knack for quotes. I like this one in particular, because its witty enough -- and ambigious enough -- to be used in nearly every situation about anything you disagree with at all. Kind of like Agile.

Some background

What is Agile? In a sentance: "Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project." (wikipedia) It achieves its agility through some very cool (and very non-conventional) processes like frequent deliveries, test driven development, pair programming and continual integration. There is much less emphasis on documentation and more emphasis on face-to-face communication than traditional development. It emphasizes short meetings, a client representative and some other very cool ideas. When used appropriately, it really is great. But it can get out of hand.

the problem: its just plain cool

Don't get me wrong, I've been a fan of the Agile concepts for a long time, but lately the amount of hype, and the associated ambiguity, has me frustrated. Decisions become emotional because Agile is "cool" (it is cool, by the way, but that doesnt mean its the best fit for everything). This is, as I see it, the same thing as a prejudice: when one becomes blind to other ideas, regardless of their merit, simply because they are foreign. Worse, it can take on the mindset of a crusade where the valiant (the developers) battle the heathens (the business), which, as I hope you can already tell, is exactly what a profitable tech team should avoid.

the answer: weigh costs against benefits

The key to getting the most out of Agile, not to mention the other 50 years of thinking about software process that preceded it, is to consider when it is best used to solve a problem, and when other methods or processes might be better suited. In process development, you almost always solve problems through trade-offs: when done well, you trade things you dont need for the things you do. As with any trade off, you have to know what you're losing and what youre gaining.

In the next set of blog entries, we'll begin to look at the decision factors for where and when to introduce (or restrict) agile processes in your organization.