Amen, brother! We struggled for several years to teach some flavor of waterfall in our Software Design and Development course, but the students constantly fought it. We kept telling them to do lots of up-front design and documentation, but their lack of experience with doing that sort of design (or building anything very big) made the exercise frustrating and fruitless. So they did what we made them do, and then ignored all that design work when they were finally allowed to build the system. They instinctively knew that the situation was too unstable (for a whole lot of reasons) for Big Design Up Front to make any sense.

When I read Beck’s Extreme Programming explained (first edition arguably much better than the new, second edition) it was a really blinding revelation. Beck was essentially outlining and supporting what the students had been trying to do intuitively, and which we had all too often been fighting. When we switched to use more agile methods, the success in that course improved enormously.

Having recently come upon the agile development process while working in a company that has lived waterfall for years, I had to smile at this post. It becomes difficult for me to see how waterfall ever worked on a project of any complexity. Im not sure if that is because agile fits my way thinking and working, or if it is a great explanation for how most of us work and think when tackling multifaceted projects.