|
|
|
|
|
by anamax
1553 days ago
|
|
> Why, then, did it become the predominant way to organize software projects? Because it feels good to managers. For most of the project, it gives them a feeling of control and competence. That feeling is false, as it just delays all of the real-world feedback until near the nominal end. But they can perform confidence and competence to their boss, which is vital in managerialist [5] organizations. Waterfall is not just "feels good" - it decouples their evaluation from their performance. Until the end, everything is good because there's no measurement to show otherwise. At the end, measurements that show things have gone wrong merely prove that some past manager failed. The only way to fail is to be a manager throughout the whole project, and management rotations guarantee that that never happens. It's not just software. The scheduled manager tenure at at least one of the largest semiconductor companies is one year shorter than the design->ship cycle. |
|
And I'd add that at the end of the waterfall cycle, metrics often (and incorrectly) show that the workers failed. After all, they said they were 95% done just a bit ago, and now they're suddenly not done. It's very easy to shift blame to them.
As contrast, a lot of the effective Agile techniques don't actually fix problems; they just shorten the feedback loops so problems surface sooner. That's part of why fake Agile won out; managers didn't adopt any of the bits that would make them feel uncomfortable or expose the very real problems with how they run things.