Waterfall and other process models are no excuse for bad practices, broken processes and failed projects. If you adhere to a process you don’t understand, you will build crappy software.
The Waterfall Process Model
At best people think of waterfall as a predecessor of agile development, a grandfather, a learning curve.
Waterfall is rejected by managers and teams alike. What we have come to know as “waterfall” is heavily connotated with terms like “big upfront design” (BUFD), bureaucracy and eventually project failures. When you look at the waterfall process, you probably agree with this reasoning:
“Of course it cannot work! There’s no feedback loop and no customers and no iterations. It’s programmed to fail!” – Sure… except THIS IS NOT THE WATERFALL PROCESS MODEL!
The Real Waterfall Process Model
This is it:
The waterfall process model very well included in it’s first publication back in 1970:
– an iterative and incremental approach
– a focus on requirements
– direct involvement of users and the customer
– regular critical reviews
– a focus on testing
Sure, it says, “complete program design before analysis and coding begins”, but this probably is a good idea. (Wie war’s gemeint?)
Do you really think teams in 25 BA (=before agile) never showed a user a part of their software product to get feedback? – Of course they did! And of course it did work. – Due to the direct and painful nature of feedback (link to article on “Feedback in SE”).
Funny side note: Royce stated exactly the problems, that are usually cited regarding the waterfall approach: “prone to failure, inept…”
The intention of the waterfall model was to improve this situation. That’s why Royce proposed his new model.
You might have ranted about waterfall yourself. – That’s ok! We’ve learned from change management that it helps teams to have a scapegoat to blame bad practices on. – In this case, it’s not even a person, which is great.
Wait, What Did You Say About Crappy Organizations?
My point is: If you adhere to a process you don’t fully understand, you’re probably learning and that’s fine. But if you adhere only to some parts of the process and some day surrender and say:
Some real life examples (with subtext):
- “It doesn’t work here, because we are too big / too small / too different.” (We are unique!)
- “We did this and that and left out the things we didn’t like.” (We need a scapegoat.)
- “We didn’t get this to work. This process is broken.” (We’re not bothering.)
Lesson Learned: Learn from the past!
As an engineering discipline we cannot let ourselves down to blaming process models for our own disability or unwillingness to use the methods and processes that are appropriate to the task at hand.
Agile development and especially Scrum is in wide adoption. But as with the waterfall approach other development approaches will come. And then we all will say: “Yeah, pretty dumb what we did with Agile until 2020, but it was a stepping stone to the NewAweSome (NAS) development process models everyone uses today.”
The lesson here is that many organizations are not even using the tools,
methods and processes that are known to be efficient in a given context. And: Never judge a model by its common practice!
Latest posts by André Nitze (see all)
- 7 Reasons Why Low-Quality Software Actually Costs More Than It Saves - June 22, 2017
- Pricing Software Projects Without Leaving Money On The Table - June 22, 2017
- “Quick-and-Dirty” is Fake News - June 21, 2017