Agile vs Waterfall. Why?

Every week it seems like I read, see or hear someone positioning Agile as some sort of opposite of Waterfall.  I understand why people do this – it’s a shortcut of sorts.  However I feel it can be extremely shortsighted and a potential conversation-killer, especially when people in positions of authority or of significant influence are the ones doing these comparisons.  It’s even worse, in my opinion, when Agile practitioners do it.

Waterfall, as a software development approach, is largely a straw-man.  If you don’t believe me, read the source that seems to have started it all. And yet, even if you believe Waterfall is real, recognize that it is primarily (if not solely) focused on the process aspects of developing and delivering software.

Agile, on the other hand, and in my opinion, is a cultural approach (future posts will explore this) to software development.  This culture has been adopted outside of software development.  Agile is not only concerned with process.  It is concerned with both the people and the practices involved in software development.

So while Agile is about incremental and iterative software development (which is why its often pitted as an opposite of the straw-man that is Waterfall), that’s not where it ends. Agile informs how we organize to address our software development challenges.  Agile addresses the importance of engaging those who will use our solutions during the development process (as does Royce’s paper by the way).  Agile emphasizes paying attention to our technical practices and improving as we progress.

So instead of comparing Waterfall with Agile – which reminds me of people who compare the United States with Africa (thinking Africa is a country) and I’ve met quite a few of those people in my day – let’s have meaningful conversations around the aspects of the way we work that we’d like to improve.