Not much different, really. Most of the so-called agile features existed before with different names. Waterfall is widely caricatured to contrast with agile, bu

Not much different, really. Most of the so-called agile features existed before with different names. Waterfall is widely caricatured to contrast with agile, but I rarely saw it work much differently in practice. Having worked with both, and after getting certified as a Scrum Master (for what that’s worth), I think the main difference is how much analysis and planning gets done in advance of coding. Too much and the process gets locked up in analysis paralysis and over-ambitious plans (and schedules). Too little and the team has false starts and can veer too far from requirements, or discover important requirements too late. The defining bad characteristic of waterfall is getting stuck doing a lot of planning and then the plans and schedule don’t change or take customer feedback into account. This doesn’t have to happen but it can and does. The defining bad characteristic of agile is getting stuck with a lot of half-baked code programmers have their egos invested in, before requirements are fully understood. This doesn’t have to happen either, but it does. One thing I like about waterfall is having the goals and roadmap defined, so everyone has the big picture. The goals and map might change but everyone sees the changes. In the agile/scrum projects I’ve worked on many didn’t have clear goals, map, or a shared vision, the “conceptual integrity” Brooks writes about. Cards with user stories doled out in sprints aren’t a big picture. One thing I like about agile is acknowledging up-front that generating complete and unambiguous requirements in advance is impossible for any non-trivial project. Requirements will evolve from feedback and collaboration and discovery. But without a shared vision of some kind it’s just a jazz odyssey, to paraphrase from Spinal Tap.