Project managers tend to get very all-or-nothing about their favourite methodologies. A suggestion of anything less than 100% requirements coverage is invariably met with folded arms and cries of “cowboy approach” while huge requirements documents elicit calls of “useless” and “won’t be read”. Maybe the biggest reason for these emotive responses is a lack of knowledge of the “other” approach. As somebody once said, “you can’t reason somebody out of something that they weren’t reasoned into”. Well, sometimes “Waterfall” is the way to go, for example when implementing the same product multiple times. And “Agile” certainly has its place whenever requirements are not fully understood. But, while much has been written about these methods, it is not always clear what the actual differences are. After all, you end up with pretty much the same documentation in either approach, just written at different stages in the project.
For me, the single biggest divergence is in the design phase. Waterfall tends to go for a big design up front whereby requirements are painstakingly detailed and “perfect” supporting documentation (such as plans) lovingly created. Agile, on the other hand, aims for an “enough” design up front ethos whereby the most important overriding principle is the technical excellence associated with a final solution created in an iterative fashion as requirements emerge. The way that people are managed (and treated) is another area that separates the methodologies. Waterfall teams are generally treated as plug and play elements that require oversight (by an overzealous project manager) to do the job well and overtime to get it done on time. Agile, on the other hand, represents more of a democracy. The agile project manager never tells the team how to do their jobs, attempting instead to create a high-performance, self-organising unit through motivation and the mantra of sustainable effort (if there’s too much to do, do less). This simplified approach, adapted throughout the project (if something isn’t working in Agile then change it), replaces the fixed command and control style adopted in Waterfall endeavours. Another big difference is the point at which the customer is engaged and how their input is welcomed. Whereas Waterfall prescribes customer involvement at the start (requirements) and end (acceptance testing) of an engagement, Agile mandates continual involvement so that the customer’s reaction to each slice of functionality is used to guide the next iteration of the final product. Indeed, even advocates of Waterfall methodologies would have to admit that, for them, customer engagement at the wrong time is at best a risk and at worse a pain in the behind. The final deviation is in the area of communications. The “inbound” messages on a Waterfall project are generally document-based (if you don’t write it down, it doesn’t exist) and “outbound” status reports reflect milestones reached and tasks completed. In stark contrast, Agile advocates face-to-face communication over writing things down and the actual delivery of final solution components as the only guide to real project process.
As a final thought, I would suggest that the only real way to decide which approach is appropriate in a particular situation (I’m not writing either off) is to ask the following question: “if it was your money, what would you do?” Answer that, and you will know which way to go on your next project.