Agile: It Is Not Because of Waterfall

When reading articles on Agile methodology, it occurs to me that a lot of people are victims of Waterfall. This shows because there are endless comparisons, when elaborating on how useful Agile approach is, between Agile and Waterfall.  What strikes me as peculiar is that when I am preaching Agile approach to others, I was also comparing this with Waterfall.

The reason that this is interesting, is that I don't think most people were victims of Waterfall. Rather, most of us are victims of the nameless chaotic situation that we can blame Waterfall for.  Don't get me wrong, I am all for Agile and not a bit for Waterfall. However, knowing where we are coming from is important, when we are trying to figure out a way out of the chaos.

I have been working in the software development field almost evenly between small companies and large corporations for almost twenty years. I haven't seen anything that came close to a formal Waterfall process being explicitly or implicitly executed. The only glimpse of Waterfall that I had, was in a rare job interview a long time ago. There I was presented with a thick design specification armed with glossy papers, carefully chosen fonts and nicely done layout and with fancy schmancy UML diagrams.  Since it was only an interview, so it doesn't count. I can also guarantee you that most developers you run into, especially on Wall Street, have no idea what Waterfall means. The first thing comes to mind would be Niagara Falls.

The point is, for most of us, the need for Agile development methodology is really not because we hate Waterfall that much (although it is pretty bad, in my mind anyways). We are more concerned with a better way to come up with a working computer program that our bosses, our customers and, perhaps more importantly, ourselves will be satisfied. The reason Agile appeals to us, is because it breaks things into manageable pieces in terms of functionality and resources. Therefore, it is not chaotic.

Because of this, I am not overly concerned about whether Agile is tool-based or human-interaction-based. I don't really care too much about the yellow stickers and the whiteboard, or the need for people to sit in room so they can casually communicate verbally. Not even the stand-up meetings. Those are not the key features; and they may not even need to be nice-to-haves. (The meeting is important, I would probably insist, but the format is not.)

By the way, this is one of the reasons why I don't see a conflict between Agile and CMMI. Please see my earlier articles for this.