Think of waterfall as being similar in concept to the old USSR central planning of the economy. Think of Scrum as similar to a market economy.

— Ken Schwaber

Project X hit a milestone called Vision/Scope seven months ago, 99 days late. It’s 312 days late on the current milestone, which is called Definition.

To date, the project has consumed 36,000 labor hours — 18 person-years — and $2.5 million.

At this morning’s enterprise-level status meeting, it was decided that Project X will be put on indefinite hold, as it is no longer a strategic priority.

This reminded me a lot of an article I read a few days ago:

What the waterfall does well is to keep useless projects from resulting in useless code that needs to be maintained. I’m not sure if that’s the real purpose, but it’s certainly a great side benefit. It may sound inefficient to pay a lot of engineers to get started on projects, do a bunch of analysis and design, and finally abandon the whole thing when something else becomes a higher priority, but every line of code they don’t write is another line that can’t break!

OK . . . you could make a case that waterfall “worked” here — clearly if, after 18 years of effort, people can’t even define the project, that sounds like a project that has no chance of success and shouldn’t be attempted — but it worked at a cost of $2.5 million.

That doesn’t seem very efficient.

What I find is that if you put the customer, the technical team and other appropriate representatives together for as little as four to eight hours, à la a Sprint Planning Meeting, it should be obvious whether or not anyone understands the problem well enough to go ahead and attempt a software solution.

Thus spoke The Programmer.

There have been a number of criticisms of the standard waterfall model, including

• Problems are not discovered until system testing.
• Requirements must be fixed before the system is designed — requirements evolution makes the development method unstable.
• Design and code work often turn up requirements inconsistencies, missing system components, and unexpected development needs.
• System performance cannot be tested until the system is almost coded; undercapacity may be difficult to correct.

The standard waterfall model is associated with the failure or cancellation of a number of large systems. It can also be very expensive.

— “The Standard Waterfall Model for Systems Development”

We are so unprofessional it is incredible. The legacy of waterfall is so dominant it is scary.

— Ken Schwaber

And the Gileadites took the passages of Jordan before the Ephraimites: and it was so, that when those Ephraimites which were escaped said, Let me go over; that the men of Gilead said unto him, Art thou an Ephraimite? If he said, Nay;

Then said they unto him, Say now Shibboleth: and he said Sibboleth: for he could not frame to pronounce it right. Then they took him, and slew him at the passages of Jordan: and there fell at that time of the Ephraimites forty and two thousand.

— Judges 12:5-6

Thus the original meaning of the word “shibboleth”: a password that people from one side can pronounce but their enemies can’t.

The word has since taken on a more general meaning as not necessarily a password, but a custom or practice that separates the good guys from the bad guys, the insiders from the outsiders.

Continue reading Shibboleths

This essay by Turing Award-winner Fred Brooks is almost 20 years old now. Sadly, the ideas on incremental development are still considered outside the mainstream in IT, which continues to favor the widely-discredited waterfall approach.

Continue reading Respect the Classics, Man: No Silver Bullet