The "red herring" of waterfall is rising again. The proponents of agile use waterfall as the whipping boy (or girl) for what's wrong with software development processes. What is completely lost here is:
All processes are serial in the end. Steps are taken one at a time, in some order. The old saw:
In the control systems world - and one of the anti-serial process authors claims to have been a control systems engineer - the sampling time in the control loop determines how responsive the loop is to change.
- Sample slow, respond slow
- Sample fast, respond fast
Of course it's not quite that simple, but that's the rudimentary principle. You're house thermostat has a few minute sample time, plus a delay for restart, plus a dwell time for shut down. Same for the air conditioner compressor. Your cruise control has a difference sample-compute-response behavior. Our crappy 1997 Suburban cruise control used to hunt when climbing I-70 west of Denver. It was not tuned to the engine, the load, or the grade, but taken from the Chevy Impala - like the A/C compressor. The flight controls for a 777 have difference response times than the controls for Joint Strike Fighter.
A "design, code, test" cycle in months has a different response time than one that samples the resulting output in a month, two weeks, or even a day.
All processes are serial in some form. Parallel activities can take place, but the value stream is usually serial. If it were parallel there are concurrency issues, integration stabilization point issues and a hoard of other artifacts caused by parallel developments.
- Serial is good
- Serial means least rework
- Sample times MUST be tuned for the context and domain
Any control system engineer knows this. You can learn more starting here.
