Agile has become so popular among software professionals that we sometime refrain from criticizing it for fear of being tagged as "behind", "old school" or downright stupid. Fortunately, experienced IT professionals know better and acknowledge that Agile has limitations.

Allow me to play the devil's advocate.

Agile was created in large part in reaction to the predominant - and now infamous - waterfall model, and to a lesser extent to all "traditional" methodologies. But did we question the assumption that Agile was indeed superior to traditional methodologies? Although many projects using traditional methodologies failed, many others were successful. Do we have reliable evidence to back the assumption that Agile methodologies are more successful than traditional methodologies such as IBM RUP, CMMI, Prince2, or RAD? The truth is we don't.

Better questions would be:

• When does Agile make sense compared to traditional methodologies?
• How can we combine Agile with traditional processes to better address a specific situation?

In order to try answering these questions, we have to look at the limitations of Agile. During the next weeks we will briefly look into these limitations one by one. The list below is a draft of the limitations I can think of out of the top of my head, and is therefore subject to change. I'll add the links to individual posts as they come.

1. A team of stars
2. Fit with organizational culture
3. Small team
4. Collocated team
5. Where's my methodology?
6. Team ownership vs. individual accountability