Ron Jeffries has a post A Metric Leading to Agility is which he claims that agile's role is to shoot waterfall in the back.
Who in their right mind does waterfall?
It seems only the software development community missed the death of waterfall in the early 80's. I work in a very high ceremony environment - planning, designing, building, and flying manned and unmanned spacecraft. No one would EVER suggest that we plan a multi-billion dollar program using a waterfall approach. Massively parallel Integrated Project Teams (IPT) working in an Integrated Product and Process Development (IPPD) paradigm requires iterative and incremental development.
The waterfall example in Ron's post is correctly completely lame. If a planner laid out such a plan, she would be asked to find another program to practice her 1980's skills.
So why is Waterfall still the Stalking Horse for Agile?
For some reason ""waterfall" is the favorite fall guy for how not to do software development projects. My personal opinion is that the proponents of agile (my self excluded of course) don't really know how projects are run outside of their own experiences. They are certainly bad software development projects that use poor planning processes - waterfall being one. But these approaches are flawed to begin with.
The agile approaches don't seem to ask - what is the best practice currently in use outside these "bad apples?" If you came and looked at an Integrated Master Plan for our program it would have many of the same attributes of an incremental and iterative approach used by XP or Scrum - more Scrum like actually.
Waterfall is not used in any viable aerospace, heavy construction, or infrastructure development project. Project planners, program managers, cost estimators and Cost Account Managers (CAMs) all learned this in the late 1980's
It's time to stop using Waterfall as the whipping boy of bad project management process. As Dog Bert recently said...
Change Happens, Get Over It
